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Ty ee eeRODUCTIO 


Computer programs have become an indispensable part of 
research, development, and practice in virtually every area 
of science, mathematics, and engineering. The development 
of software in these areas has all the problems with the 
economic production of correct and reliable software systems 
that other areas of computer applications have and some 
special problems such as numerical precision, and the need 
for significant computation, as well as some unique assets, 
such as programmers and users with a solid understanding of 
mathematics. Below we will argue that the scope of computa- 
tions in this area together with a shared set of problems 
makes the production of software for science, mathematics, 
and engineering a prime candidate for the development of 
software tools to lessen the problems and increase the 
productivity of programmers working: this area. 

A. THE IMPORTANCE OF FORTRAN IN SCIENCE, ENGINEERING AND 

MATHEMATICAL FIELDS 

Wayne R.Cowell and Webb C. Miller emphasized the impor- 
tance of Fortran in the science ,engineering and mathemat- 
ical fields as follows [Ref. 1: p. 3]: 


Numerical computation is a larger proportion of the 
total computing activity than_ is commonly believed. To 
illustrate, the Department of Defense, for which much 
computation is of a numerical nature, operates more than 
twenty five times as many computers as the Internal 
Revenue Service and the Social Security Administration 
combined. A study of the matter led John Rice to 
conclude that numerical computation accounts for about 
590 % of the computing expenditures in the United States. 


Fortran has been the language of choice for scientists, 


mathematicians, and engineers for many years. Even through 
the development of other languages (for example : Prolog, 
Pascal, and C-language), its position seems’ solid. For 


thal 


example, a survey [Ref. 2: pp. 147-162] of commercially 
available project control systems which are widely used in 
the construction industry, gave the following data: 

* Fortran 21 (4122 


¢ Cobol 2 {23.5 7) 
e Assembler 2 aa %) 
e others 9 (17.6 %) ; several software systems were 
composed of more "Pak one language. 
Finally, Fortran is viewed by many as an excellent 
language for science, mathematics, and engineering computa- 
tion: The primary reasons for this view are: the wide 


availability of language processors accepting programs 
written to the current standard (particularly for advanced 
scientific machines); the stability of the Fortran implemen- 
tations; the general purpose nature of many of the facili- 
ties offered by the language; the highly efficient object 
code, particularly for scientific computation; the wide 
availability of high quality programs and subroutine 
libraries written in Fortran; and finally, the prevalence of 


> 


Fortran in scientific computing environments. 


B. PROGRAMMING ENVIRONMENTS 

It has been estimated that the cost of producing soft- 
ware in the United States in 1980 was between $30 billion 
and $40 billion [{Ref. 3: p. 17]. Other estimates place the 
cost of producing software at between $40 and $200 per line, 
depending upon the size and nature of the problem and the 
software development team. It seems clear that a major 
reason for this high cost is that nearly all of the activi- 
ties associated with software production are manual. It has 
also been clear for well over a decade that many of the 
manual processes could and should be assisted or replaced by 
computer supported capabilities. Such computer assistance 
invariably has taken the form of software designed to help 


humans perform the activities which are necessary in order 
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for them to accomplish their software related jobs: coding, 
testing, documention, transporting, designing and 
maintenance. 

The software programs created to assist in software 
activities have come to be called software tools. There has 
been a great surge of interest in creating software tools in 
the past ten to fifteen years. Unfortunately there has not 
been the expected decrease in the cost of producing software 
nor the expected increase in the quality of software 
products. 

In fact, it appears that, despite the apparent appropri- 
ateness of using software to help software people, few soft- 
ware tools have been adopted enthusiastically or widely. 

The term "programming environment" or "computing envi- 
ronment" is often used denote the set of computer-based file 
structure, system services (including languages), and system 
access methods available to assist the programmer [Ref. 4: 
De 39). 

" Recently there has been a rapidly growing interest in 
Programming Support Environments (PSEs). While relatively 
few such environments actually exist at the present time, it 
would appear that over the next few years a number of such 
systems will evolve. Although the development of PSEsS is in 
its infancy it is already the case that it is often very 
difficult to compare two proposed or extant systems. One 
problem which contributes to this difficulty is the lack of 
agreed upon terminology. Another problem is the extreme 
diversity of functionality which might be desired of or 
provided by some PSE. 

In the following section, there is a discussion of the 
various kinds of programming activities which a programming 


support environment might support. 


als 


die Some Programming Actiyities 
As a preliminary to proposing some ~ tCerminologysand 


some comparative axes we will present some paradigms of the 
kind of activities which might be carried out during sere 
life cycle of some engineering projects. We will rely 
heavily on pictorial representation of the activities in 
this section. 


1) Revision 





Here the left and right boxes represent text which 
1s modified by using some editor to, for example, make it 
more complete or to correct certain errors which have been 
discovered. 


2) Compilation 


Compiler 


[| 
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Here the box represents source text for some collec- 
tion P of program entities and the bottom represents object 
code. 


Another picture of compilation is 






Compiler 


Here the box labelled A represents the results 
derived by analysis of the program entities (for example, to 
determine types, identify common subexpressions, assess 
relative frequency of paths, or what have you). 


Yet another picture might be 


Target=Vax 


Compiler 


Target=Vax 





Where the box labelled G represents inputs to the 
compiler that directs it to produce code for the VAX. 
OF) eae taide 





Here the box labelled L represents a (virtual) 
listing appropriate for the combination of the "dexme- 
labelled?) 2. 21) 0 


4) Transform 
Pe Ei 


Transformer 
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Here we depict the refinement of some collection of 
program entities (the upper box labelled P) by some trans- 
meommation ((T). Examples include using preprocessors to 
translate from a problem specific language into some stan- 
dard high level language, derivation of a procedural speci- 
fication from a non-procedural specification, using program 
transformation to refine abstract constructs in a wide spec- 


trum language, and so on. 


5) Aggregate 





Here we might be putting together some "system" (S) 
composed of components P, Q, and R. 


At some later time, after revision of R, we might have: 


Editor 





a7 


6) Analyze 





Here the upper box represents 
program entities and the lower 
analysis of these entities. 

7) Probe 


some collection of 


represents the result of 


Probe 


Here the upper box represents some collection of 
program entities and the 


lower represents the results of 
probing these 


entities during program execution to gather 
various run-time statistics. 
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Here we depict the "packaging" of several components 
(P,. . .,Q) into some derived result (R). Examples include 
Mmemeangs Object code preparatory to loading, preparing a 
Gemeiling context, and so on. 


9) Families 


Target 
IBM4431 


Transformer © @ Transformer 


Target 
IBM4431 


Here we depict the specialization of a general 





compiler specification (the upper box labelled C) to two 
particular compilers (the lower boxes) for, say, an IBM 4431 


and a DEC VAX. 


ao 


Another example is provided by the following: 


type=COMPLEX 
precision=l 
type=REAL 
precision=2 
y Transformer 


Transformer 


type=REAL 


precision=2 


type=COMPLEX 


precision=l1 





Here we depict specialization of some general mathe- 
matical software package (the upper box labelled M) to two 
particular packages for specific number types and preci- 
Sions. We shall speak of the two lower (C) boxes in the 
preceding and two lower (M) boxes in the above as’ two 
members of a family. 


Zz. Some Functional Aspects OL Programming SUppErE 
Environments 


Having armed ourselves with a collection of terms to 
describe various aspects of programming support environments 
and the activities supported by a PSE we now want to iden- 
tify anumber of axes along which we might measure and 
compare environments. 

1) Language Support 

A first question we might ask about a programming 
support environment is how many programming languages are 
supported and how well .integrated is the support if there is 


more than one language available. 


yale 


Pa Larget Configuration Support 

It is becoming widely recognized that the computing 
complex appropriate for supporting the activities of program 
development and maintenance must be reasonably large-quite 
often larger than that appropriate for the operational 
system being developed. Thus a PSE may support more than one 
target configuration and, for example, use cross compilers 
to support target configurations quite different from the 
host. 
3) User Interface 

Having a user interface which makes a PSE easy and 
natural to use is very important. 
4) Command Language 

By the command language for a programming support 
environment we mean the set of expressions which the user 
employs to direct the activities of the PSE. This may be a 
special language similar to a job control language or may be 
an extension of a programming language available .in the PSE. 
In general, it is important that the command language be 
easy to learn and use and that its interpreter be robust. 
5) Integration of the Tools 

The tools of a PSE are always "integrated" in the 
sense that they are part of the PSE and they take their 
inputs from and deliver their results to the software tools. 
Indeed, the set of programs which can be executed on any 
operating system are integrated in this very loose sense. 
Given that a PSE is more structured, it is possible that the 
tools within a programming environment can be quite highly 


integrated, resulting in a number of advantages. 


Pall 


6) Granularity of fools 

Typically the tools for program development provided 
within the context of most operating systems are few in 
number and large grained. For example, a "compiler" is typi- 
cally a single tool which operates in several phases: 
parsing, analysis, optimization, code generation, assembly, 
and so on. Similarly, an editor typically operates ona 
complete "file" and leaves no explicit record of what was 
changed and what remained invariant. 
7) Relationships Supported 

Conventional programming languages and program 
development tools provide few facilities for explicitly 
describing the relationships among the various program enti- 
ties comprising some software system. Rather, such relation- 
ships are usually represented only implicitly. 
S) Protection 

There are a number of levels at which PSES may 
offer facilities which enable modules or parts thereof to be 
protected from alteration or use by unauthorized parties. 
9) Documentation Support 

There is a great variety of documentation which is 
associated with a program system during its lifecycle. 
Included are items as diverse as requirements documentation, 
software trouble reports, user manuals, progress reports, 
time and cost estimates, queries about status, and new 
release updates. There are, in turn, diverse ways in which a 
programming environment can support the preparation of and 


dissemination of documentation. 


Zz 


II. OVERVIEW OF TOOLPACK 


Since about 1970 a number of individuals and groups 
developing mathematical software have begun developing at 
least moderately elaborate software tools to assist in 
making their software available on a variety of computers. 

As mentioned in the previous chapter, Fortran has been 
the language of choice for numerical computation, its posi- 
tion seems more solid now than it was ten years ago. 

The TOOLPACK project was initiated few years ago with 
the goal of addressing the problem of inadequate and inef- 
fective use of software tools to develop scientific, engi- 
neering, and mathematical software. 

The project currently is managed by a confederation of 
researchers from seven different institutions (Argonne 
National Laboratory, Bell Telephone Laboratory, Jet 
Propulsion Laboratory, Numerical Algorithms Group,LTD., 
Purdue University, University of Arizona, and University of 
Colorado at Boulder) [Ref. 4: p. 15]. 


This confederation has concluded that the roblems of 
gnetfective and inadequate utilization of software tools 
is attributable to the generally poor quality of such 
tools as well as to the absence of a unifying framework 
within which they can be evaluated, coordinated compared, 
and upgraded. Thus the TOOLPACK project has, essentiall 

Since its inception, been directed towards the goal o 

mEoducing ada quality tools, and imbedding them in an 
effective integration framework. Further, the avowed 
aim of the Pye eet has been to make this set_ of tools 
and integration framework generally available to’ the 
mathematical and scientific software community. 


TOOLPACK/1 is the first release of the TOOLPACK Fortran 
software tools suite. It is the result of an international 
collaborative project started in 1979. The project was 
supported by the Department of Energy and the National 


Science Foundation in the USA and by the Science and 
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Engineering Research Council in the United Kingdom. In 
making TOOLPACK/1 available, NAG (Numerical Algorithms 
Group) is acting as a distribution agent on behalf of the 
TOOLPACK council. 
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III. METHOD OF EVALUATION 


A. INSTALLING TOOLPACK 

An important issue in the use of programs, tools, and 
environments is how easy it is to install and use them. 
Installing a system, whether a new one or an existing one 
that has been modified, consists of the three primary activ- 
ities of training, conversion, and post-installation review. 

Training involves both system operators and users who 
will use the new system either by providing data, receiving 
information or actually operating the system. Training the 
system operators includes not only how to use the system, 
but also how to diagnose malfunctions and what steps to take 
when they occur. The users need to be trained to operate 
the system. 

The conversion plan describes all the activities that 
must occur to install the new system and put it into opera- 
tion. It identifies the tasks and assigns the responsibili- 
ties for carrying them out. The conversion plan should also 
anticipate the most common problems, such as missing docu- 
ments, incorrect data formats, lost data, and unanticipated 
system requirements, and provide ways for dealing with them 
when they occur. 

The post-installation review not only assesses how well 
the current system is designed and implemented, but also is 
a valuable source of information that can be applied to the 
next system project. 

We will evaluate the difficulty of installing and main- 
taining the TOOLPACK environment in chapter 7 (Installation 
on VAX/VMS). 
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B. RUN-TIME COMPARISON 

This thesis uses the benchmark technique to compare the 
elapsed CPU times of executing several of the TOOLPACK 
tools. The selected program sizes are classified into 85 
lines of code (LOC), 700 LOC, and 1500 LOC. The overview of 
the benchmark tests and actual data analysis are described 
in chapter 8 (Capabilities of System and Tools). 

Most operating systems and some special program tools 
are implemented in their own system level languages or in 
lower level languages (e.g., Assembler language) to increase 
the performance. But in order to be portable over several 
different machines, the TOOLPACK project uses high level 
languages (Fortran-77 and some Pascal); the use of high 


level languages causes lower performance. 


C. COMPARISON OF THREE ASPECTS 

The TOOLPACK project was originally designed for scien- 
tists, mathematicians,and engineers not in the computer 
science field. This thesis will compare the goals: of 
TOOLPACK with the needs of programmers of mathematical soft- 
ware and compare the goals of the TOOLPACK project with the 
actual capabilities of the TOOLPACK project (See Figure 
3.1). To compare the three aspects, some knowledge of them 
is required. Therefore, the author will introduce each 
concept in the following chapters. 

Chapter 4 will describe user's view (views of scien- 
Elscs- mathematicians and engineers). Chapter 5 will 
describe the initial goals of the TOOLPACK project. Chapter 
6 will describe the configuration of TOOLPACK project, 
Chapter 7 will discuss the problems of installation on 
VAX/VMS. Chapter 8 will describe the actual capabilities of 
TOOLPACK project. Chapter 9 will compare the needs, goals, 


and capabilities described in the preceding chapters. 
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Milgure “3. 1 The Comparison Aspects. 


IV. GOALS FOR TOOLPACK | 


From the workshop of the TOOLPACK project team came the 
following outline of the capabilities that TOOLPACK could 


provide to Fortran programmers ~PRet.1- spp oc): 


1). A structured Fortran language which enhances stan- 
dard Fortran with modern control and data strue= 
tures. Such a language can contribute substantiall 
ie. pole ae eae a permitting the use of, environmen 
parameters (Such as the ost machine Ss précisten 
and overflow limit) and by Pore the generation 
of both single=-precision and ouble-precision 
Fortran from the same version of the program. 


2) Fortran program template processors which facilitate 
the production of Fortran preprocessors for problem 
statement languages. 


3) Static .data-flow analysis. A tool based on DAVE 
[Ref. 6 can detect such. data-flow anomalies. as 
variables that _ are assigned values but never refer- 
enced, variables that are referenced before being 
defined, and variables whose values may depend on 
whether the values of local variables are retained 
between subroutine calls. The static analysis Capa- 
ages et! could include a way of testing executability 
of paths in numerical programs. 


4) Instrumention of Fortran programs with )code ere 
MONICOY GxXeCucion charac eerie rec: 


5) Formatting of FPoreran Geena. 


6) Precision type conversion (double to single and 
Single to ouble), for application to existing 
programs. 


7) Conversion of standard Fortran to structured Fortran 
with automatic selection of appropriate control 
structures. 


8) A eneral=purpose source to source. transformation 
system in the spirit of TAMPR [Ref. 5: pp. 542-546]. 


9) A text editor with built-in knowledge of Fortran 
syntax. 


Besides Bega y rae integration of the above capabilities, 
the pack tradition demands integration of the software 
thac el ela the capabilities. For that reason, the 
highest-level tools should rest on : 


10) A common base of flexible components, including 
lexical analyzers,parsers,table managers,and report 
generators. 


28 


A summary statement of the goals is continued in 
eet. 19: p. 85]: 


Weeedeomeliot 15 to provide a suite of tools to aid the 
POrtran Pr Ogmammee in the production and maintenance of 
medium-sized mathematical software projects. 


¢ The second is to investigate the development of exten- 
Sible pace eee pee Support environments built around 
integrated tool suites. 


The TOOLPACK architectural design document of 1982 
[Ref. 7: p. 3] contains alist of objectives for the 
project. Ordinarily one would not expect any additional 
goals to be included in such a document. Portability (see 
5, below) was elevated from a factor in the original project 
to a full status as a goal. As we shall see in the discus- 
Sion, this decision to make portability an explicit goal has 
had a major impact on the design of TOOLPACK and on the 
ieee y Of TOOLPACK: 


1) The mathematical software whose production, testing, 
transportation and analysis will be supported bY 
HOOLPAGCK is cou Demy ike con in a Give Le Gia © 
Fortran-77. This dialect is to be carefully chosen 
to span the needs of as broad and numerous a user 
community as 1S practical. 


2) TOOLPACK is. to provide cost effective support for 
the production y up to 3 programmers of programs 
whose length is eee 2000 lines of source text. It 
may be less effective in supporting larger projects. 


3) TOOLPACK is. to provide cost effective support for 
the analysis and 1s ee ea sce ae of programs whose 
length is up to 10,000 lines of source text. It may 
be less effective in supporting larger projects. 


4) TOOLPACK is to support users working in either batch 
oe interactive mode, but may better support interac- 
ive use. 


5) TOOLPACK is to be highly portable, making only weak 
assumptions about its operating environment. IT will 
be designed, however, to make effective use of large 
amounts of primary and af ten memory, whenever 
these resources can be made available. 
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V. MATHEMATICAL SOFTWARE : CHARACTERISTICS, PROGRAMMERS 
AND PROGRAMMING ENVY LRONMEN 





This chapter discusses the current state and foreseeable 
evolutions in software development for scientific, mathemat- 
ical, and engineering applications. In evaluating software 
support it 1s critical to identify the target user group and 
to characterize their background, jobs, work conditions and 
attitudes. Consideration of the factors that are likely and 
unlikely to change in the foreseeable future will make it 
possible to identify the feasible opportunities to improve 
software development for mathematical software. 

It is widely thought that there will be a steady growth 
in the size and complexity of mathematical software. This 
growth will present new problems and with them new opportu- 


nities to improve programmer productivity. 


A. DEFINITIONS 

The central focus of software for scientific, mathemat- 
ical, and engineering applications is numerical computation. 
We want to define numerical computation rather precisely so 
as to distinguish it from business data processing, symbolic 
processing (such as compilers), and general utilities (such 
as file manipulation systems or job schedulers) [Ref. 8: pp. 
687): 


Numerical computation involves real numbers with proce- 
dures at a mathematical level of trigonometry, college 
algebra, linear algebra or higher. 


some people use a somewhat narrower definition which 
restricts the term to computation in the physical sciences 
and afew people even think of numerical computation as 
research and development computation (as opposed to produc- 


tion) in science. 
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Another definition has been suggested by Wayne R. Cowell 
meet. 4: p. 37]: 


Since about 1970, the term 'mathematical software' has 
been understood to mean computer programs that perform 
the basic mathematical computations of science and engi- 


neering. Someone characterizes the effort to produce 
Machematical software as the building of bridges between 
the numerical analysts who devise algorithms and the 
computer users who need efficient, reliable implementa- 
tions of those algorithms. 


In what follows we use the term "mathematical software" 
to refer to software for scientific, mathematical, and engi- 
neering applications and "programmer" for thosé people that 


write this type of software. 


B. PROGRAMMERS 

Mathematical software is primarily written by people 
with little or no formal training in computer science or 
computer architecture. These people have training in 
science, engineering or mathematics andcall themselves 
Mereitscs, engineers, etc, rather than the less prestigious 
"programmer". Although many of them spend the majority of 
their time doing programming, they regard the computer and 
programming to be a tool that they use in the work in their 
Basic field. Throughout their careers these people will 
retain their primary allegiance to the basic field of 
science, mathematics, engineering that they were trained in. 

There are relatively few computer scientists doing this 
kind of work because extensive training and experience in 
the area of application is required. In general, it is 
easier to teach scientists, engineers and mathematicians 
programming than to teach computer scientists the basics of 
an area of application. There is a group of numerical 
analysts and computer scientists whose major interest is in 
mathematical software. Their contribution has been signifi- 
cant and influential but they are and will remain a tiny 


minority of the people developing mathematical software. 
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Our characterization of the majority of programmers who 
work on mathematical software is that they have a mastery of 
the basic aspects of Fortran, a sophisticated view of algo- 
rithms and performance analysis for programs in their domain 
of interest, and a knowledge of structured programming. Blt 
they are not aware of basic concepts in algorithms to do 
symbol manipulation, language translation, and compiler 
theory nor are they aware of contemporary software develop- 
ment methodologies. For example, the concept, design, and 
coding of a program that has a computer program as it input 
data is beyond scope of their knowledge. 

Since these programmers view computers and programming 
as a tool to do their work, they are very reluctant to learn 
new computer science ideas, concepts, algorithms, and tech- 
niques unless they are absolutely convinced that immediate 
and significant benefits will follow. Although they are 
very interested in innovative topics in their basic field, 
they are very conservative in their approach to new program- 
ming topics. Also their lack of basic training in contempo- 
rary computer science makes it difficult for them to learn 
new topics by reading the computer science literature. 

The ignorance of computer science of most people that 
write mathematical software is equaled by the ignorance of 
most computer scientists about numerical computation. Many 
sophisticated scientists produce naive software just as many 
sophisticated computer scientists produce naive science. 

Another important fact is that most mathematical soft- 
ware is written by a single programmer (or a small team). 
Thus there has been little pressure for program standardiza- 
tion. Also most mathematical software is maintained by the 
person who wrote it, so there is no compelling reason to 
develop documentation standards. 

Most proyrammers in this area spend their entire profes- 


Sional career working in a single area of application. They 
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therefore have little opportunity to see software developed 
tomocier areas. This limited view of software together with 
an absence of a literature to present mathematical software 


has lead to their limited view of software development. 


C. LANGUAGE 

The most obvious feature of scientific programs is the 
language in which they are written : an overwhelming 
Majority are written in Fortran. Some competition has come 
from PL/I and Pascal, the latter being popular in some 
circles especially for the implementation of prototypes, 
eoack and dirty" TERENAS. etc.; both, however, remain 
marginal. 

Many sites have done some experiments with Pascal in 
order to assess the fashionable language, but few have used 
it on actual projects, since most scientific programmers who 
have tried it deeply resent the lack of features they 
consider essential. Minor criticisms are of the absence of 
exponentiation, separate compilation and the inefficiency of 
run time checking. A major impediment has been the strong 
typing of arrays that includes their dimension , this has 
made it impossible to construct general purpose procedures 
to do array manipulations. Although the ISO standard now 


allows a remedy, it is still not widely available in Pascal 


compilers. 
So Fortran is still king. It should be noted, however, 
that the world is not so simple as it used to be: Fortran 


means different things to different people. The Fortran 77 
standard has not completely taken over; it many cases, what 
is available is still either a compiler based on the 66 - 
standard, usually complemented by machine-dependent exten- 
sions, or some hybrid between the 66 and 77 versions. At 
the same time, some manufacturers are taking (high-risk) 
bets on the next standard being concocted by ANSI, referred 


to as Fortran 8X. 
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When talking about Fortran with respect to mathematical 
software, it is impossible not to mention an apparent 
paradox: in spite of its almost undisputed position asa 
vehicle for writing numerical software and its pretentions 
to portability, Fortran does not as yet offer any tool for 
controlling the numerical accuracy of programs in a portable 


fashion. 


D. APPLICATION DOMAIN AND NEED FOR EFFICIENCY 

The application domains of mathematical software are 
matrix calculations, linear systems analysis, and simulation 
of given engineering conditions in narrow applications. The 
most complicated application domains are control systems of 
nuclear power plants. These Kind of applications need high 
reliability. They also need high quality (1l.e., optimiza- 
tion) compilers. 

There are two principle sources of the problems in the 
application of mathematical software: mathematical models of 
the physical world and the optimization of models of the 
organization world. The scope and range of the sources and 
the associated software is illustrated by the following list 
[Ref. 8: pp. 688-689]: 


1) Simulation of the effects Of multiple explosions: 
The software is avery complex program. of perhaps 


20,000 Fortran statements. t is Seecta ay tailored 
GO Eis heer es and may have taken several years to 
implement. The program requires all the memory and 


many hours of time on he largest and fastest 
computers. 


2) Optimization of feed mixtures for a chicken farmer. 
This is standard software of modest length (500-2000 
statements) even with an interface for a naive user. 
[It might take substantial Lime to emecuve on ay smanm 
computer (for example, mini-computer and personal 
computer ). 


3) Analysis of the structural vibration of vehicle. 


The software is similar to that of example 1. More 
computer time and memory would be used by this 
approach. 

4) Simple linear regression on demographic data. This 
is standard software, but classical algorithms are 
neither reliable nor robust. Modern algorithms are 


short 200-400 statements) and execute quickly 
except for exceptionally large data sets. 
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5) Optimization of design parameters of a gyroscope. A 
mathematical model of a complex physical system is 
required and then optimization algorithms are 
applied. Determination of the gyroscope performance 
for a single set of parameters mage involve the 
solution of a system of partial differential equa- 
tions. Considerable human interaction is probabl 
used to avoid astronomical computer costs and ye 
achieve some reasonable progress toward the optimum. 

6) Calculation of the cabhacaey of the wing tank of a 
jet liner. thes 1S a simpLe problem except for the 
eomplex geometry of the wing tank. Once the wing 
tank is broken into simple pieces (probably by a 
Berson) then standard algorithms are reliable, short 
and erficient. ie aucomatlc processing of the 
complex shape requires much more sophisticated soft- 
ware of moderate size ett 2000 statements), but 
still gives a short calculation. 


The demand for efficient compiled code has lead manufac- 
turers to produce sophisticated optimized compilers. These 
compilers are expensive to build and maintain and have 
achieved some of their efficiency by developing manufacturer 
unique extensions to Fortran that exploit unique character- 
istics of the hardware. 

The demand for efficiency has lead to a reliance on high 
quality compilers for Fortran with extensions. This has in 


turn lead to major portability problems with Fortran. 


E. PROGRAMS 
1. Size 
scientific programs vary considerably in size. A 
typical range is between 2,000 and 50,000 source lines 
(whether or not one counts comments usually has a marginal 
influence on the evaluation). There are bigger programs, but 
they are not so common; some packages reach 300,000 lines or 
more, but one seldom hears about sizes comparable to what is 
often quoted about e.g., telephone exchange software 
200,000 to million or more). Thus much mathematical soft- 
ware can be characterized as "medium-size". 
There are many signs, however, that these figures 


may growing steady. The pressures toward larger programs 
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include : more extensive computations, more "user friendly 
interfaces", more error checking of input data and results, 
and more extensive reports and high quality display of 
results. This tendency is likely to bring about much 
concern regarding the scaling up of the methods’ used for 
program writing and project management. 

In other areas of computer science the growth in the 
size of programs has lead to new problems ; among these are 
the problems associated with having more people involved in 
the development and maintenance of the programs. Also the 
development of programs for use by many people at many 
different locations presents new difficulties with training, 
documentation and maintenance. 

2. Contents 

We outline below some of the characteristics of 
mathematical and engineering software as we perceive them 
and as they distinguish this type of software from others 
such as business software (acCcouncing, transaction 
processing and the like), real-time software (command/ 
control etc.), systems software (compilers, operating 
systems, teleprocessing etc.), or office informatven 
systems. These characteristics relate to the form and 
contents of the programs and to the way they are produced 
and used. 

There is still a widely held view that mathematical 
programs are essentially computation-oriented. In ett 
experience, this is inaccurate. Of course, most mathemat- 
ical programs include some non-trivial arithmetic computa- 
Enon: he oe however, one looks at the actual code, one 
frequently finds out that the part which actually performs 


numerical computation is relatively small in size (if not in 


execution time), the bulk of the program text being 
concerned with manipulation of data structures, storage 
Management, input and output, pre- and post-processing, 
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error identification and exception handling, etc. In a 
large part, mathematical programs are data manipulation 
programs. In most cases, this part 1S growing much faster 
than the purely numerical one, which is often relatively 
stabilized; many developments have to do with improvements 
in the user interfaces, inclusion of interactive facilities, 
graphical input and output, uses of data base managements 
system, etc. 

This aspect of mathematical programs should be 
understood by those who design new machine architectures, 
programming languages, software tools or methods aimed at 
this area. 

3. Use of Extensions 

Most programmers are aware of the non-standard 
Fortran extensions on their computers and recognize that 
their use restricts portability of programs. Despite this, 
most programmers feel that the use of non-standard features 
is necessary to achieve the maximum run time efficiency. 

4. Programming Style 

Mathematical software does not in general have a 
consistent program style. There is not any standard or 
commonly used programming style in mathematical software, 
most programmers have developed a unique approach that is 
not consistent with any contemporary approaches to software 
development (for example, cop aownmac Sl gil, information 
hiding, stepwise refinement). In addition, most programs do 


not display any consistent approach to program organization. 


F. DEVELOPMENT ENVIRONMENT 
Peete | Lodram Library Concept 
The idea of building a library of modules that could 
be reused in other programs was an early concept in Fortran 
software development. It is still very important. This 
Gomeepe Nas been surprisingly difficult to bring to fruition 


in the same sense as a library of books. That is to Say, 
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widely available and good quality libraries for basic mathe- 
matical procedures did not become available until the 1970's 
and even now most computer users lack access to°a_ good 
library of programs for mathematical software. This is in 
spite of expensive efforts by IBM and other computer 
manufacturers. 
The author would like to classify mathematical soft- 

ware libraries into three types : 

2) Low level (utility function) library. 
The libraries of this type are basic mathematics, trigome- 
trical functions and are widely used in mathematical 
programming. The illustrations of this type library are SQRT 
Gecqtiare root), SIN, COS, and EXP, etc. 

Z) Middle level library. 
The libraries of this type do simple mathematical, statis- 
eacal, and graphical functions. The algorithms of the 
programs are simple and easy to understand. Most libraries 
are used independently by a single user and do not support 
an integrated scheme. Most users could write and modify 
these programs. The illustrations of this type are IMSL 
(International Mathematical and Statical Libraries, Houston, 
Texas) and NAG (Numerical Algorithms Group, Oxtord, 
England), etc. 

3) High level library. 
The libraries of this type are large specialized application 
packages which provide integrated algorithm schemes. The 
vast majority of the users of these packages understand the 
action of the algorithms but do not know the coding details. 
The examples of this type are LINPACK, EISPACK (a systema- 
tized collection of programs for eigenvalue problems), and 
NASTRAN (a structural engineering package), etc. 

The library concept 1s based on the fact that many 

problems are of a somewhat standard nature and occur in many 


different contexts. This 1s especially true of numerical 
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computation because scientists and engineers use the 
language of mathematics in their analysis. 

The methods one uses seem to be independent of the 
particular computer and thus expressible in some machine- 
independent Fortran subset. eh eee 's ol. Algol and their 
descendents have made it possible to attempt to develop the 
science, art and body of numerical computation software. 
Even with these advances, the significant differences among 


compilers has hindered progress. 


2. Tools , 
The use of programming tools, beyond such standard 
ones as editors and compilers, is fairly limited in many 
installations. It is remarkable to see, for example, how 


often the machine-format dump still plays the role of the 
basic debugging aid. Here again, the discrepancy in levels 
of abstraction between the sophistication of the applica- 
tions and the people who conceive them , on the one hand, 
and the characteristics of the underlying software, on the 
other hand, are striking. Also, one can again notice the 
negative effect of the language : although Fortran is much 
more primitive by its concepts than, say, Pascal or Lisp, 
it is often less amenable to language dependent tools such 
as syntax-directed editors, symbolic debuggers etc. because 
of its baroque features, strange format and irregular 
structure. 

Mathematical software has also been the prime target 
for other successful tools: Fortran static (and, to a lesser 
extent, dynamic) analyzers. Again, these tools are unde- 
rused; it is clear, however, that they can provide a host of 
services which, although conceptually limited, are extremely 
useful in connection with the development, acquisition, 
debugging and documentation of mathematical software. 

Although it is true that some of the checks 


performed by Fortran static analyzers (for example, type 
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checking) are only needed because of the language's defi- 
ciencies, this 1s only part of the picture; some of the 
ideas could be profitably adapted to more elaborate 
languages, which are still lagging behind Fortran with 
respect to availability of such tools. 


G PORTABILITY 

While everyone recognizes the potential savings from 
distributing good software, it has been hard to achieve even 
when good, usable software is written. The dependency of 
mathematical software on machine word length as well as the 
eccentricity of compilers and operating systems pose formi- 
dable barriers to the dissemination of quality software. 

It has been shown that portability and top efficiency 
cannot be achieved simultaneously in a high level language 
like Fortran because of compiler variations. A 100 % loss in 
efficiency may be an acceptable price to pay for portability 
in some instances, but there are even more severe problems 
“with error handling, precision changes (double precision to 
Single precision or vice versa), and arithmetic unit 
behavior. These difficulties should be isolated and methods 
found to overcome them in an automated system. 

One method to obtain program portability is to define a 
standard widely accepted language and then write preproces- 
sors that translate programs written in it to a language for 
which a good compiler exists. The most notable such effort 
in mathematical software is the RATFOR (Rational Fortran) 
language [Ref. 9: pp. 285-318] that extends Fortran and is 
transformed into Fortran. There have been several problems 
with this approach : 

1) The preprocessors are somewhat difficult to write and 
ee corde thine. TORS WARD Ehe 
2) The resulting Fortran is very hard to read and thus it 
SeMrae catieccti ae cOpmocdity Or Optimize 


3) Any error messages are reported in terms of the 
Fortran program rather than the RATFOR program. 
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Another problem for portability is the spread of small 
machines such as micro-computers (personal computers) and 
mini-computers. These machines are so numerous that it is 
not possible nor economical to do a careful job on the math- 
ematical software (which may be permanently implemented as 
micro-code). 

The manufactures of such machines are frequently unaware 
of quality software principles and portability software for 
mathematical software. The result has been numerous 
instances of inadequate algorithms-both in the hardware and 
in manufacturer supplied libraries and systems (for example, 


the Fortran builtein functions). 


H. HUMAN ASPECTS AND PROGRAM TECHNOLOGY 

Everyone agrees that human engineering of software is 
important, but so few people do anything about it. There 
have been instances of mathematical software that was widely 
used because they had good human engineering even though the 
results computed were unreliable. These and other experi= 
ences have convinced many (but far from most) developers of 
numerical software that the human engineering (user conven- 
ience) aspects are critical. This is, in itself is a mile- 
stone; unfortunately there have been few advances in how to 
do human engineering. It still seems to take a lot of hard, 
patient work. 

Professionals in mathematical software have always had 
their favorite methods for various kinds of problems (there 
is not a general methodology for mathematical programming). 
Occasional surveys show that there is no consensus among the 
experts as to which methods are best. Even worse, for many 
years, most people did not distinguish between a somewhat 
vague method anda computer program implementation of the 
method. Now people realize that the implementation (soft- 
ware) is as critical as the method, as there can be (and 


have been) terribly poor implementations of good methods. 
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There are two main variables here [Ref. 8: p. 688]: 
different implementations of the same method and different 
methods for the same problem. It is not at all easy to 
design frameworks in which meaningful comparisons can be 
made. However, in the late 1960's such comparisons were 
started for ordinary differential equation software and now 
the framework for this particular area is well defined. 
Since then there have been significant accomplishments in 
evaluating software for numerical integration, special func- 
tions, linear algebra and polynomial root finding. 

Finally, there is a notable lack in the use of "program 
proof methods" for software for mathematical software. Some 
reasons for this are 


Zt is Giertoult to 2ncomporate the umeertainties of 
round-off into proofs. 


e the software tends to be too long for current proof 
methods 


* most numerical computation software has parts whose 


performance cannot be specified in terms of input- 
output relationships 
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VI. CONFIGURATION OF TOOLPACK 


A. THE TOOLPACK TOOL INTEGRATION CONCEPT. 

The TOOLPACK tool integration concept is centered around 
the notion) Ekac software tools must be focussed on 
supporting the creation and deep understanding of a large 
and complex mass of information=-namely the software under 
development. It seems that software workers often attempt to 
view their jobs in this way, but that they are most often 
thwarted in their attempts to exploit this view by system 
software. 

Thus the TOOLPACK project 1s attempting to create a 
Portable Software System (PSS) which can be profitably and 
effectively viewed and operated as a system for the manipu- 
lation and management of the large, complex and multifaceted 
object which is the software program under development. 
This section will present a necessarily brief overview of 
the integration software which was developed for the 
TOOLPACK project. The entire system of tools and the encom- 
passing integration software has been named the Integrated 
System of Tools (IST). 


B. THE“! Pepeows eel 

As above indicated, the central focus of the TOOLPACK 
command language is the creation, accessing and maintenance 
of the data repository whose aim is the faithful and suppor- 
tive represention of all the data which the user needs in 
order to perform needed software work. This represention 
seems to be effectively achievable by portraying the soft- 
ware are ae structured, coordinated set of views’ and 
versions. 

In TOOLPACK these various views and versions are all 
stored as files. Thus the heart of TOOLPACK is a file 
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system. This file system actually consists of two parts : 
the host filestore (HFS) and the portable filestore (PES) 
eere 14: p. 5]. 

HES files are simply formatted -files in the host system 
filestore. They are always accessible to host system utili- 
ties. The virtual machine makes no assumptions about an HES 
directory structure and the only assumption about the names 
of HFS files is that they may not exceed maxpath-1 charac- 
ters, which maxpath is a virtual machine constant set by the 
imotaller. To identify an HES file, the user adds a one- 
character prefix (usually '#' but installation-dependent) to 
its name. This "host file-id" character is stripped off the 
name before it is used. 

PFS files reside ina tree structured directory system 
Similar to that provided by VMS system. A directory in the 
tree structure may contain files or other directories. 
Conceptually, the directories may be nested to any path, but 
there are practical limitations, such as the maximum length 
of name. PES files may not be directly accessible to stan- 
dard host system utilities. 

In addition to these disk files there are four precon- 
nected files available to tools. These files are available 
in all operating regimes. These files and their symbolic 
names are as follows [Ref. 14: p. 6]: 


meiner standard input file ( stdin ), normally associated 
with the user's keyboard. 


2) The standard output file ('stdout'), normally associ- 
ated with the user s terminal. 


3) The standard error reporting. channel ('stderr'). The 
associated of this channel is host dependent but is 
often the user's terminal. 

4) The standard list channel ('stdlst'). The association 
Soecimo channel 15 Nest dependent tor connection to a 
spooled system printer noua aigts may be connected to 
a fixed file that can be printed by the user. 

Almost all files within the HFS and PFS are formatted 
sequential, but formatted direct access file capability is 


provided. 
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C. THE VIRTUAL MACHINE (TVM) OF TOOLPACK 

To provide the capabilities of the TOOLPACK tools and 
command interpreters on as wide a range of machines as 
possible, a definition of the TVM was produced to which all 
TOOLPACK programs comply. The TVM includes definitions of 
the character set, directly structured and minimum machine 
capabilities that must be provided on the host computer 
before TOOLPACK programs can be used. 

The TVM capabilities are actually accessed by the tools 
Via the Tool Interface to the Environment (TIE) library. In 
order to make the capabilities of the TVM available, it is 
necessary to have an implementation of the TIE library on 
the host machine. A portable version of the TIE library, 
written in Fortran-77, is provided in the TOOLPACK software 
Suite to allow as many users as possible to at least try out 
TOOLPACK capabilities. 


It is probable that a single x eo ee aa of the portabiiaiey 
base ‘will be undertaken in the light of experiences 
gained as a result of the production, distribution and 
use of the first release. If this does happen, great 
Care will be taken to provide a support mechanism for 
all existing tools, with a compatible upgrade path. Any 
new design would be aimed at producing a smaller, more 
aPPeererece and more easil ge Spang dees ane core Library 
of routines for the TIE [Ret 1323 p.o 


The main features of the TVM are as follows : 


1) A stream-based input/output system for files and 
preconnected units. 


2) A fixed internal character set and variable-length 
string handling. 


3) A tree based directory structure and defined file 
eee convention in a Portable Filestore (PrayP 
normally separate from the Host Filestore (HES). 


4) A defined process-scheduling and argument-passing 
capability. 


5) Extensible capabilities by the use of supplementary 
libraries. 


By splitting the TIE library into several sections it 


has been possible to allow greater environmental flexibility 
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mor the use of tools. Picesp bites  shownein  Fagure 6.1, 
which shows that there are three sublibraries to the TIE; 
common, input/output, and flow-of-control. 

The common sublibrary contains general-purpose routines 
to convert character types, manipulate strings and recover 
the date and time. There is only ever one version of this 
library ina TIE implementation. 

The input/output sublibrary is concerned with the provi- 
sion of the stream based input/output routines and the 
directory handling capabilities of the PFS. There may be two 
separate implementations of this sublibrary, one of which 
provides the full capabilities of the HFS and PES, as 
defined for the TVM, and the other which maps) all input/ 
output and file access to host files and ignores directory 
handling routines. The two versions of the sublibrary 
contain the same routines with the same apparent (to the 
tool) functionality so no code changes are required to use 
either version. 

The flow-of-control sublibrary 1s concerned with the 
initialization and termination of TOOLPACK tools, process 
scheduling and argument passage. There may also be’ two 
versions of this sublibrary, one which allows process sched- 
uling and the other which does not. 

The provision of multiple versions for some of the 
sublibraries allows for a variety of levels of implementa- 
tion of the TIE and lets the tools be used in a variety of 
environments without modifications to the source code. This 
flexibility can be useful during the TIE implementation 
phase, during tool development and for those users’ who, 
while wanting access to the capabilities of TOOLPACK tools, 


are not interested in the provided command interpreters and 


EE The possible environments available are as follows 
meet. 13: pp. 3-4]. 
1) Embedded : This is the full environment defined for 


the TVM. Both the PFS and HFS are available and tools 
may be scheduled from TOOLPACK command interpreters. 
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Library Librar Library fjoptional) 





Portable 


Filestore 


Host Machine and Operating System 


Figure 6.1 sections of the TIE Library. 


Ze} 2 Lae eee : This environment still allows tools to 
access both the PES and the HFS but assumes that tocow 
pgp gee is performed direct from the host operating 
system. TOOLPACK command interpreters will not be able 
to schedule tools in this mode. 


3) Stand-astride : This environment provides the_ same 
flow-of-control capabilities as the embedded mode but 
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aceess to the PFS is not possible; all I/O operations 
are Peneed. ameotatcay ly Tome eho Hes sanar dlrectory 
management is not possible. 

4) Stand-alone : In this mode, tect scheduling is 
performed direct from the host operating system as in 
stand-atop and the same file access restrictions apply 
as for stand-astride. (The installation of this thesis 
is stand-alone mode. ) 

The TVM definition can be extended in any area by the 
use et TIE Supplementary libraries. The current 
Supplementary library includes access functions for token 
streams and parse trees, extended string handling, pattern 
matching and data structure handling. The access functions 
provided allow easy access to, and manipulation of the lower 
level representations of program units. These lower level 
facilities greatly ease the production of custom Fortran 
manipulation tools by users; a tool writer may freely manip- 
ulate a token stream Knowing that it can be generated for 
him and that the modified form can be easily returned to the 
source text. 

Before TOOLPACK tools or command interpreters can be 
used it is necessary to have an implementation of the TIE 
library available. The TIE implementation may be available 
in the following ways : 


1) The portable TIE implementation may be installed on 
the host. 


Z) A. customized TIE implementation may be produced, 
either completely new or a modification of the 
portable version. 

3) An available customized implementation may be used. 

While it may seem that providing an implementation of 
Gae TIE is a lot of work, it is likely to take less effort 
than mounting a comparable suite of monolithic tools that do 


not conform to a portability base. 
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VII. INSTALLATION ON VAX/VMS 


The installation of TOOLPACK is avery  diftficule race 
On the VAX/VMS 11/780 VMS system it took several months to 
get the most basic "STAND-ALONE" mode up and running. The 
documentation is voluminous, difficult to read and the 
material is not presented in the same order as the steps 
that are necessary for installation. Without additional help 
that was found only after numerous phone calls around the 
country, it is not possible to successfully install the VAX 
version. As noted in the documentation, the NAG office can 
not (and other than providing user telephone numbers did 
not) provide help with the installation. The help of Larry 
Reed of the National Energy Software Center was pivotal in 
getting the installation completed. The author is indebted 
to him for the successful installation. 

The expenditure of resources was quite large. The author 
worked for several weeks reading the documents. It was then 
determined that the task was beyond the capabilities Oe 
someone who was not an experienced VAX systems programmer. 
Andrea McDonald, a systems programmer on the staff of the 
Computer Science Development, then worked on the installa- 
tion on and off for 2 months. During this period all the 
files were established, corrections posted, programs 
compiled and libraries established. It later was found that 
much of this work was unnecessary to set up the VAX/VMS 
STAND-ALONE mode. Finally with several calls to Larry Reed 
and the simultaneous help of Andrea McDonald and my thesis 
advisor both working full time for two and one half weeks we 
were able to get several of the basic tools working. 

By the time the system was finally installed, a new 
version of TOOLPACK had been released. It was decided to 


start the installation completely from the beginning and 
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install version 1.4. The VMS/TIE installation took one week 
(60 hours plus) of full time work to establish the file 
system, read in the files, post and document in the code all 
mmewGorrections »for 1.2, 1.3 andi1.4, and establish the 
libraries. An additional week was needed to post the correc- 
tions in the individual tools, compile the tools, test the 
tools and build VMS EXECS to execute the tools. This two 
weeks of work was begun immediately after the first instal- 
lation, so the full Knowledges of that installation allowed 
the second installation to be done in the minimum possible 
time. 

The author's advisor documented the second installation 
so there would be a permanent record of the steps necessary 
to install the VAX/VMS STAND-ALONE version of TOOLPACK. That 
description is now in draft form; a decision on publishing 
it as a technical report is awaiting TOOLPACK version 2. HFG 
is likely that after modifications to accommodate version 2 
it will be published as a technical report. The present 


draft is over 30 pages. 
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VIII. CAPABILITIES OF SYSTE TOOLS 


A. GENERAL. 

There are basically two major classes of methodologies: 
Single_module testing, and multiple-module testing (or 
system testing). The goal of this section is to explain a 
base line of understanding about the processes that apply in 
typical quality assurance circumstances. 

A way of determining how to work a testing methodology 
is to examine the characteristics of various methods against 
a backdrop of some typical situations. The four cases we can 
employ for this purpose are: 

1. Case a: A high-criticality single module. 

iz Case b: A medium-sized, medium-criticality system. 
3. Case c: A large, medium-criticality system. 

+ Case d: A large, high-criticality system. 

Case a is in a high-level language, it is may be 250 to 
500 statements long, andit has a very complicated control 
structure. It has many different things to do, and it must 
be error free. 

Case b is a set of about 25 modules that support an 
on-line facility of some kind. If the software system fails, 
there is no serious loss because there is an automated back 
up system; however, it iS expensive in terms of lost produc- 
tion and associated waste. The system is written ina struc- 
tured extension of Fortran and containes about 6,500 
statements overall. The calling depth in the structure of 
the system is between 4 and 7 - not complex and not flat. 

Case c 1S a comprehensive system for control of a 
facility, and itis 80% ina high-level language like 
Pascal, Fortran, or Ada and 20 % in an assembly language. 
The total volume of code is in the range of 175,000 lines of 


code. If this system fails, there is a substantial loss of 


a 


wmelue, but no lives would be lost, and the damage would not 
normally be extensive and/or expensive to repair. 

Case d 1s a geographically dispersed interactive control 
system where human life 1s at stake-like an advanced air 
traffic control system. The system approaches the limits of 
current complexity in the sense that the latest methods are 
employed in its design and implementation, perhaps 1,000,000 
lines of code overall [Ref. 11: p. 376]. 

We would classify the TOOLPACK into multiple_module and 
Case c (A large, medium-criticality system). 

Another software system evaluation methodology is bench- 
mark testing. Benchmark testing is the application of 
synthetic programs to emulate the actual processing work 
handled by a computer system. Benchmark programs permit the 
submission of a mix of jobs that are representative of the 
users’ projected work load. They also demonstrate data 
storage amounts and provide the opportunity to test specific 
functions performed by the software system. Through this 
technique, the limitations of the system become apparent 
early in the acquisition process. Sometimes user organiza- 
tions will insist that the results are attached to software 
system specifications, formally stating that a specific 
number of transactions can be processed in a given period of 
time, the response to an inquiry will be within a stated 
amount of time, and so forth. 

Benchmarks can be run in virtually any type of system 
environment, including batch and on-line job streams, and 
with the users linked to the system directly or through 
telecommunication methods. Common benchmarks are the speed 
of the central processor, with typical programs executed in 
a set of subprograms, as well as multiple streams of jobs in 
a multiprogramming environment. The same benchmark run on 
several different computers will make speed and performance 


differences attributable to the central processor apparent. 
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Benchmarks also may be centered around an expected 
language mix for the programs that will be run, a mix of 
different types of programs, and applications having widely 
varying input and output volumes and requirements. The 
response time for sending and receiving data from terminals 
is an additional benchmark for the comparison of systems. 
Sometimes, rather than running actual benchmark jobs on 
computer system, system simulators are used to determine 
performance differences. In commercial systems simulators, 
the workload of a system is defined in such terms as : how 
many input and output operations there are, how many 
instructions are utilized in a computation, and the order in 
which work is processed. The specifications are fed into a 
Simulator that stores data about the characteristics of 
particular equipment (such as instruction speed, channel 
Capacity, and read=-write times). The simulator in turn 
processes the data against the operating characteristics and 
prepares a report of the expected results as if the actual 
computer were used. Then the systems characteristics can be 
changed to mimic another model of computer and a new set of 
performance data produced for comparison. The time and 
expense of running actual benchmark programs on a computer 
is of concern to analysts and specification alike. Thus, the 
use of commercial simulators 1s an attractive alternative 
{[Ref. 12: pp. 586-588]. 


B. EVALUATION AND OPERATIONS PROCEDURE UNDER VAX/VMS 

Up to present, we have discussed the general principles 
of evaluation techniques. I selected the evaluation method 
benchmark testing for this thesis. As mentioned above, the 
installation of TIECODE is not a Embedded regime, but it is 
a STAND-ALONE environment. 

Therefore, the STAND-ALONE regimes allows the tool 
writer to make use of the TIE library without the need for 


either the IST (Integrated System of Tools) command 


ore 


interpreter ( ISTCE) or the portable file system( PES). liye 
this regime, atimetiber 1/0 is ‘directed to» host files 
regardless of the manner of the file access requested. Tools 
operating in this regime are executed directly from the host 
operating system, to which control is returned on completion 
[Ref. 13: pp. 3-5]. The appendix A eit 
TOOLPACK/1i-Introductory Guide [Ref. 14: Dp: 1-10] has 
examples for the Embedded regime, is not for the STAND-ALONE 
regime. Therefore, the author followed the procedures of 
Tutorial Examples of the TOOLPACK/1l-Introductory Guide, but 
some procedures do not work in the STAND-ALONE regime, as 
will be pointed out in following sections. Some selected 
TOOLS, for example ISTPL and ISTPT used the benchmark 
testing technique (time comparison with different size 
programs). 

For the benchmark testing, the author produced the 
programs which are a modifications of a Command program 
under the VAX/VMS System (Version 4.2). Liles program 1S 
attached in Appendix A. 

The TOOLPACK Manual has the descriptions of the input 
parameters and the output parameters which are the parame- 
ters in each tool. But this kind of expression is not very 
helpful to the users. Therefore, this thesis uses the D.F.D. 
(Data Flow Diagrams) conventions which are more understand- 
able, readable, and extensible than TOOLPACK's [Ref. 17: pp. 
47-124]. 

Especially, the D.F.D. conventions are very useful to 
represent a lot of parameters which are combined for more 
than two tools. 

is ISTLX (Fortran- scanner). 

a. Description 
ISTLX is a Fortran-77 scanner that converts 
Fortran-77 source text to a token stream and detects and 


reports lexical errors. The scanner has been mechanically 
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generated from a specification of the Fortran-77 language 
| Ref. 1s: spel 

ISTLX reads Fortran-77 source text from. the 
source file. The resulting token stream is placed in the 
token file and the comments are placed in the comments file. 
Any errors discovered are reported to the error file and an 
attempt is made to continue scanning by deleting or adding 
tokens. During operation the scanner produces a list file 
which contains the input source text preceded by the token 
number of the first token for each statement. 

ISTLX is the first step in using each tool. 
Therefore, if ISTLX produces an error file, then the user 
should COLBEGCE the source text programs which are 
Fortran<-77 source text. 

There are a lot of users who are using the 
WATFIV source program [Ref. 16: pp. 65-101] at Naval 
Postgraduate School. The user must be careful with the 
control structures of- WATFIV programs which are not admitted 
by TOOLPACK. Figure 8.1 shows an example. 


PES Lash aee 95 THEN 
ELSE DO ELSE 


END IF END IF 


( WATFIV ) ( STANDARD ) 





Figure 8.1 WATFIV control structure. 


Jey The Flow of ro li. 
Figure 8.2 shows the parameters using the D.F.D. 
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List. far le 
#SAMPLE.LIS 


ror. ft.Lle 
#SAMPLE.ERR 


source. frle 


#SAMPLE .FOR 
token. file 
"#SAMPLE .TKN 


comment. frle 
#SAMPLE. CMT 





Figure 8.2 The Flows of ISTLX. 


c. CPU Time Comparison 
The CPU Time comparison of different size 
programs is shown in TABLE I. 


TABLE I 
CPU TIME COMPARISON OF FStLx 


(unit : secs) 


Poeogsamn saze §| so LOCs| 9700 LoCry, 1500 LOC 


Z 
5 





2. JSTYP (TOOLPACK Parser) 
a. Description 


ISTYP parses a Fortran-77 program. It takes as 
its input a token stream produced by ISTLX (Fortran-77 
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Scanner) and produces a parse tree, symbol table and comment 
index [Ref. 18: p. 3]. 
| All error and warning messages produced by ISTYP 
are written both to the standard error channel and the 
symbol table file. When a tool which uses the symbol table 
is executed, these warning and error messages are displayed 
again. AS many error conditions render at least part of the 
symbol table or parse tree information invalid, it 1s impor- 
tant that the user is aware of the possiblity that further 
processing may be completly useless. 
b. Them@ilowssor [sive 

To execute the ISTYP, the previous step which is 
the running the ISTLX is required. Therefore, the users 
would follow the Birqure ~8.3 (tne sg: tons mof Mot ye The 
command file which is to execute the ISTYP is Appendix B. 


c. The Problems Using The ISTYP in the VAX/VMS 
system 


In chapter 7, the author already mentioned the 
problems associated with the installation of the TOOLPACK. 
The version of the distributed TOOLPACK is TOOLPACK/1, 
Version 1.4. But, this version stills need a lot of 
corrections. 

The TOOLPACK programs are composed of many 
modules. Therefore, if we correct some modules then we have 


to correct the related modules. These kind of jobs are not 


easy. If the installer is not careful in identifying and 
applying all the relevant corrections, then errors arise 
that are very difficult to trace. The difficulties in 


installing and maintaining the programs seem all the more 
ironic since the aims of the TOOLPACK project were to 
provide a suite of tools to aid the Fortran-77 programmer in 
the production and maintenance of medium sized mathematical 
software projects [Ref. 19: p. 85]. 

One example of the problems encountered was the 
attempt by the author to apply TOOLPACK to a 1500 line 
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lust frle 
#SAMPLE.LIS , 
parse tree file 
#SAMPLE.TRE 


source file As, symool table frle 


#SAMPLE.FOR #SAMPLE.SYM 


#SAMPLE.CMT 


comment wndex frle 
#SAMPLE.. CMI 


#SAMPLE.ER 





Figure .$.3 The Flow of ISTYP. 


Beperan // program. The program was executed by ISTLX 
Gemeectly, but it failed in ISTYP. The reason was that 
"String_size" is defined to 7500 in the YPDEFS of ACCESS 
FILES Directory (for example : define (string_size, 7/500) ). 

After the problem was found, the author changed 
the definition statement from "define (string_size,7500)" to 
"define (string_size,15000)". Then, the execution times of 
the ISTYP jumped to over 1.5 hours, eventually this program 
was terminated. Until the problem is corrected, the users 
of the Naval Postgraduate School version must limit its use 
to less than 1,000 lines of code. 
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oe ISTPL. (Polishing Tool) ATSTPO™( Optom hilestaiver 


a. Description 

ISTPL is a formater for programs written in 
Fortran-77. It takes a token stream produced by ISTLX, and 
produces a text file containing the formatted program. It is 
controlled by an option string from an option file (if the 
option file is not supplied then the program uses’ the 
default settings), together with any command-line options. 
The source program of Fortran-77 must be "lexically correct" 
in the sense that it may be analyzed by ISTLX without 
producing errors ret. 20-6 o 

As ISTPL makes no use of the original source 
file, it may be used as an "unscan" program which turns the 
token stream into text. When ISTPL detects an error, it may 
sometime be able to recover from it and continue processing 
the user's program. In this case the error message will be 
inserted into’ the output file as a comment beginning with 
"C*PL*ERROR*" (see Appendix C). 


There are two Kind of flows to execute the 


LSE i: One is the simple execution with the default 
settings. The time of the execution is faster than the 
others. 


The complex flow shows the more sophisticated 
output possible with use of the option file. But the time 
of execution is longer. The usage of the methods is depen- 
dent on the users. The simple flow is shown by Figure 8.4 
and the complex one is shown by Figure 8.5. The command 
files that are to execute the ISTPL are Appendix B. 

b. Option File Specification 


An epcion specification has the format 
"Parameter = Value". The actual options available are 
described in a later section. Options specified as ISTPL 


parameters 5+ (command-line options) will override option 


specifications from the -option file. Because of the large 


ao 


list file 
#SAMPLE.LIS 9” 


source file 3 ei output frle 


#SAMPLE.FOR #SAMPLE.POL 


#SAMPLE sea SAMPLE. OFT 





Figure 8.4 The Flow of the ISTPL (Simple Method). 


number of possible aisiesiome [Om (ot Lowe ane option file editor 
ISTPO is provided and is recommended for option file 
creation and maintenance. 
c. Caution of Usage of ISTPL (with complex method) 

As mentioned above, the complex method of 
running the ISTPL uses the ISTDS (a declaration standardizer 
that rebuilds the declarative parts of Fortran-77 program 
units according to a programmable template [Ref. 21: pp. 
3-4]. 

Therefore, some errors do not occur in the 
Simple Method but in Complex Method. Sometimes, the authors 
of Fortran-77 programs do not define the names which are 
External Subroutine Names (An example is shown by Appendix 
C). Nevertheless, these programs work correctly under the 
given Fortran-77 Compiler [Ref. 22: pp. 1-4]. 
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lige file comment index 
$SAMPLE.LIS @S AMPLE. CMI 


token file 


@ourae file 
——— 


SAMPLE. FOR 


Gomment file 


SAMPLE. C2 
error file 


$SAMPLE. BRE comment 
$SA4MPLE.CMT 





Figure 8.5 The Flow of the ISTPL (Complex Method). 


But if the user wants to run these programs 
using ISTPL then the following errors are reported: 
e C*PL*ERROR Unexpected statement type 
e C*PL*ERROR Unexpected <TZEOS> 
¢ C*PL*ERROR Internal Error (GRINDI)=2ZzE0S contusion 
The reason was that ISTDS was confused whether 
the name of the subprogram was defined or not in the main 
program declaration part. When the user writes the function 
subprograms, tool ISTPL doesn't report this kind of error 
message. 
Therefore, if the users of ISTPL have this kind 
of error, then they should correct the source program which 
is the Fortran-77 program. 
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di PSTE@s(Optaion Fi levEditor ) 


The following are a summarization of the useful 


contents for the users from ISTPO users' guide [Ref. 20: pp. 


12]: 
il ) 


2) 


3) 


4) 


Description : Pot POerStnegeaditOr TOs, LSOTPigoption 
files. It is menu-driven and has-~ an inbuilt help 
facility [Ref. 20: p. 12]: The only parameter of the 
fSleO 1s the Name of the Opt1en file (e.g., 
SAMPLE. OPT). 

The operation of ISTPO : When ISTPO is started ie 
will attempt to read the option file specified. ‘ie fle 
can not do this (e.g. because the file does not 


exist) ISTPO assumes that a new file is hae! created 
and all options are internally set. to the ISTPL 
defaults. Options are changed by giv ane Ehegel STPL 
option specification as a command. ption names and 
values may be abbreviated so long as they remain 


ee e, apart from token names which must be given in 
ale. 
Command Format : The ISTPO commands are : Exit, Help, 


hemi, eNece, Sate & Quit, Read, and Write. Commands ma 

be abbreviated so Long asthe abbreviation is no 

ambiguous. Arguments to these commands should be on 
the same line as the command itself, separated by a 
Space or spaces from the command name. Commands which 
oe arguments (rather than having optional ones) 
will prompt for any missing arguments. 


Command Descriptions. 


The EXIT command writes out the option file as modified 
and terminates ISTPO. There are, three forms of the HELP 
command: "HELP ‘Heit Feand Hebe topic. The first 
form displays the current ISTPO menu. The second form 
lists the topics on which help is available. MThe third 
form displays information about the requested topic. 


The MENU command moves to the specified ISTPO menu. If 
no menu name is specified following this command, then 
the current menu is redisplayed. 


The NEXT command advances to the ISTPO menu which 
follows the current one. 


The QUERY command toggles ieee mode, Whalen. aS 
initially off. In query mode, all parameter changes are 
confirmed before being done. 


The QUIT command terminates ISTPO without writing the 
option file. This command is same VAX/VMS QUIT command 
in the EDITOR mode. 


The READ command reads an option file. AAS) swale 
completely replace the curren state of the option 
memory. 


The WRITE command writes the option file but doesn't 
PemimniateekoalrO, if a tile mame 12s specified after the 
Soman then that file becomes the option file being 
edited. 
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5) Menus : ee are 8 menues in ISTPO. These are DIR, 
Baole COMM UNCOMMON ,, BLANK_LINES, LINE “BREAK, 
SPACINGI, and SPACINGS. Initially the user is at menu 
DIR, which consists of a list of the other menus and 
simple operating information. There are many options 
for the ISTPO BASIGement | Ref. 20: pp. L2Z=i18i)- 


The author selected some of them to demonstrate the results 


which are shown in Appendix C. The followings are the 
selected BASIC options : 
e INDIF = 10 ; (Indentation within a block_IF) 
¢  IOTHCO = TRUE. ; (Insert CONTINUE statement before 
previously labelled executable statement) 
¢ LMARGS = 7 ; (Left margin for statements) 
e¢ MOVEF =. TRUE. ; (Move Format statement) 
e¢ RLBEMT =. TRUE. ; (Relabel Format statement) 
e SEQRQOD = .TRUE. ; (Add sequence numbers) 
e SEQINI = O ; (Initial sequence number) 
e SEQINC = 10 ; (Sequence number increment) 
NOTES : If the user wants to execute the output 
of ISTPL immediatly, then it is recommended that the user 


does not use the option SEQEQD. The output using the SEQROQD 
isn't accepted by the VAX/VMS Fortran-77 compiler. 
e. Elapsed CPU Time Comparison 
The execution times of the different size 
programs are shown in TABLE II and TABLE III. To get the 
results, the author used almost same procedures which are 


listed in Appendix A. 


4. ISTPT (Precision Transformer) 


a. Description 


ISTET “Si-Rert. “236 }@xc 3] Sawa transform a 
Fortran-77 program from REAL to DOUBLE PRECISION or vice 
versa. The input program must have all names explicitly 


typed for ISTPT to work correctly. Thesteol ISIbs |keea 


pp. 3-4] can perform this function. 


Ba 


Jyeveneye, 30 i! 
CPU TIME COMPARISON (USING SIMPLE METHOD) OF ISTPL 


(unit : secs) 


program size | 85 Loc |] 700 LOC | (Ase Kee 


2 10.09 oO 82.15 
3 MM esl 76.29 80.91 


6. 
6. 


TABLE III 
CPU TIME COMPARISON (USING COMPLEX METHOD) OF ISTPL 


(unit : secs) 


program size [| 85 Loc ] OOM LbOCw| (sie 


Z 
3 





ISTPT takes as its input the parse tree, symbol 
table and comment index produced by ISTYP [Ref. 18: je 
3-14] and the comment file produced by ISTLX [Ref. 15: _ pp. 
1-5] and produces a new token stream file. The new token 
and comment stream produced by ISTPT can be converted to 
Fortran source code using ISTPL [Ref. 20: pp. 3-18]. 

All warning and error message produced by ISTPT 
while converting the user's program are also inserted into 
the output token stream as comments. These begin with 
"C*PT*WARNING*" and *C*PT*ERROR*" respectively. 
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Any warning and error message produced by ISTYP 
while parsing the program will be displayed on the standard 
error channel (In the VAX/VMS system they could be displayed 
on the screen of the terminals. Therefore, if the user 
wants to Keep the errors and warning messages, then use the 
VAX/VMS special commands. This technique will be discussed 
in a later section: ). They will not, however ,be inserted 
into the output token stream as comments. 

b. The Flows of The ISTPT 

There are two kinds of flows to execute the 
ISTPT. They were named the simple method and the complex 
method. As mentioned above, the simple method doesn't use 
the ISTDS (a declaration standardizer), hence the output of 
using the simple method doesn't include action on the decla- 
ration parts of the given source program. 

But the complex method uses’ the ISTDS, the 
output of using the complex method is more readable and more 
understandable than the output which result from using the 
Simple method. The complex method takes more time than the 
Simple method (The time comparison charts are shown by TABLE 
IV and TABLE V.). The user must decide on the trade offs 
between the quality of the solution and the execution time. 
The outputs of using both methods are shown by Appendix D. 
The flows of the ISTPT are shown by Figure 8.6 and Figure 
Bae 

c. Transformation Details 

This section lists the major details of the 
transformation performed by ISTPT. ISTPT should always 
produce correct output except when it detects an error, or 
with complex arithmetic. Although ISTPT does not attempt to 
ensure that the transformation will be reversible, the only 
difference will be where the code was originally of mixed 
precision, or an unusal intrinsic function (such as MAX]1) 


was used. 
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List frle parse tree 
#SAMPLE.LIS #SAMPLE. TRB 


token file token frle 


#SAMPLB. TEN 
source frle \ ee output file 
° #SAMPLE. POL 


#SAMPLE.CMT comment frle 
= @SAMPLB.CM2 


error file #SAMPLE.CMI optron file 
OSAMPLE. ERE OPTION STRING #SAMPLE .OPT 





Figure 8.6 The Flows of ISTPT (Simple Method). 


1) The key word REAL is changed to/from DOUBLE PRECISION 


2) Real constants are transformed, to/from double preci- 
sion and if appropriate "DO" will be added to or 
deleted from the end of the constant. 


3) Ihe E-format descriptor is transformed to/from the 
D-format descriptor. This will not change the "Ew. dEe’ 
form of the E-format descriptor, as there is no 
D-format equivalent. 


4) Complex variable usage will result in a rece 
message when’ convertingm@mto DOUBLE PRECISION (ISTP 
does not attempt to transform complex expressions). 

5) EQUIVALENCE statement are checked to ensure that their 
meaning does not change during the transformation; if 
it does then an error message is produced. 

d. Elapsed CPU Time Comparison 
The execution times of the different size 


programs are shown by TABLE IV and TABLE V. 
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#8. TRED 


#5u.TKs 


Sides ates 


$3u.CMIZ #3M.CuS 


$5M.Cu2 
§5M. OPT 


SM = SAMPLE PROGRAM 
TGK,.TK2,TKS © TOXEN FILE 
CuT,CM2,CMS = COMMENT PILE 
CMX,CMI2 © COMMENT INDRX 
TRE, TRE2 w=» PARSE TEER 





Figure 8.7 The Flows of ISTPT (Complex Method). 


TABLE IV 
CPU TIME COMPARISON (USING SIMPLE METHOD) OF ISTE 


(unit : secs) 


program size 85 LOC | 700 LOE | / 25 aoe 


Z 
3 
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EE Eis Vy 
CPU TIME COMPARISON (USING COMPLEX METHOD) OF ISTPT 


(unit : secs) 


program size | S35 Lod | 700 LOC oO 


2 
3 





a ISTAL (Documentation Generation Aid) 
a. Description 
ISTAL may be used to create a number of reports 


on the static and dynamic analysis of a program unit or set 


of program units [Ref. 24: p. 3]. The reports may be auto- 
matically inserted, as requested, into a specified user 
document. ISTAL uses information created by other tools, 


iMecably ISTYP and ISTAN [Ref. 25: pp. 3-16]. 

The tool ISTAN creates static analysis informa- 
tion and also instruments Fortran-77 to produce dynamic 
information on program usage. Both the static and dynamic 
information created can be processed by ISTAL. 

b. The Useful Commands to Operate the ISTAL 

There are 20 commands which are used to get the 
results from ISTAL [Ref. 24: p. 9]. The commands are listed 
in Appendix E. The author selected some of them to demon- 
strate how to work the commands. 

c. The Operation of ISTAL 

Below these are several examples which are to 
demonstrate the operation of the ISTAL [Ref. 24: pp. 10-21). 
But the examples of the reference is the result of the 
EMBEDDED regime [Ref. 13: pp. 3-4]. As mentioned above, the 
installation of the VAX/VMS system is the STAND-ALONE 
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regime. Therefore the operation procedures area little 
different. Especially, the file name convention is different 
(see chapter 6). 

The outputs of the ISTAL are displayed on the 
termimats: To keep the outputs of the operation, VAX/VMS 


commands are required. Figure 8.8 represents the commands. 


$ SET HOST/LOG = RESULT. LIS CSVMS1 
(If you issue the command, then the system will be 


logged out. The user must log in again. After log 


in, if you work anything, then all commands and 


all outputs which are displayed on the screen 
will be recorded at the list file RESULT. LIS. ) 


After finishing your jobs, type the following 


commands. 


S$ LOGOUT 
(This command returns controleeo theses lias.) 


$ PRINT RESULT. LIS 


(This command prints your jobs. ) 





Figure 8.8 VAX/VMS commands 
(to obtain the outputs of ISTAL). 


The ISTAL requires the symbol table; to get the 
symbol table, the tools ISTLX and ISTYP should be executed 
first. The important thing is that the ISTAL operates under 
the TOOLPACK command executor (ISTCE [Ref. 26: pp. 2-13] ). 
Before invoking ISTAL, therefore, the user must invoke the 
ISTCE. The summarized procedures are shown by Figure 8.9. 


oF ISTA Execution Analyzer 
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Soler to invoke the command executor) 
: Loner DLOmp ec) 
the inputs and outputs are standard 
pe fe) eee ema L 1/o)) 
ane (ISTAL prompt) 


Ailcons 
VERBOSE YES 


eile 
CALLGRAPH = #SAMPLE. SYM a eee table ame 
Cite Output of CALEG H is Appendix E 


al : 

COMMON = #SAMPLE. SYM 
(The output of COMMON is Appendix E) 

al: 

TABLE = #SAMPLE. SYM 


al : 
SYMBOL = TEST spate is the name of Main program) 
(The output of SYMBOL = TEST is Appendix E) 


al : 
Se CTH STAND (STAND is the name of the Br eens 


he output of SYMBOL = STAND is Appendix 
al ; 
WARNING = STAND 
(The output of WARNING = STAND is Appendix E) 


cele: 
XREFERNCE 
(The output of XREFERENCE is Appendix E) 


al : 
FULLAREFERENCE 
(The output of FULLXREFERECE is Appendix E£) 


eonteel Ls return to command executor) 
< ISTAL Normal Termination > 

ce : 

Oi (return to VAX/VMS system) 

< TIE : Terminated > 





Figure 8.9 ISTAL Operation Procedures. 


a. Description 
ISTAN [Ref. 25: p. 4) takes as its input a 
Fortran-77 program in token stream from (as produced by 
ISTLX) and produces an instrumented Fortran source, a state- 
ment summary file for input to ISTAL, an annotated token 


stream and a summary report. 
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The annotated token stream lists the segment 
numbers (a segment is a section of straight line code) used 
in later reports. 

It is not necessary for the input to contain a 
complete Fortran program. If only a few routines are to be 
analyzed, they may be input to ISTAN and the instrumented 
output combined with the rest of the program. 

b. The Flows of ISTAN 

The running of the ISTAN is quite complex. The 
user must pay attention to the sequence of the execution 
procedures. 

Jdabecae ce a cUbie ISTAN requires the comment stream 
and the token stream. Therefore, the running of the ISTLX is 
required by ISTAN. After getting the token stream and the 
comment stream, execute the ISTAN, then you will get the 
instrumented source codes which is a Fortran-77 program and 
many additional lines are added to get the user's output and 
some additional information named SEGMENT EXECUT Ter) 
FREQUENCIES (see Appendix F). 

A third step is required to execute the ISTPL. 
The results of this step is the polished output file which 
is an Instrumented Fortran-77 program. Figure 8.10 shows the 
Data Flow Diagram of ISTAN. 

c. The Useful Information of 1s2sn 

¢ The Instrumented Program: he instrumented progman 
produces as output a listing = fiteeana an oOpertecmam 
Single-run data file. These are ingjaddition to Wag 
output normally produced by the non-instrumente 
program. 

« The Listing Filé : The file contains @ formatted tesa 
of the execution frequencies of each segment in the 
instrumented peogeem and alist of all segments which 
were not executed. 

e Single-Run Data : The single-run data file is written 
by the instrumented program upon termination and 
COntains the “segment sexecute ft requemnc teceier )el a earaamr 
in a form suitable for input to ISTAL (The single=smm 


data file is only produced if the option is specified 
CO Tolan). 


TM 


inatrumented prograz 


@SAMPLE. PTN 
liet file statement summary 


a §SAMPLE. SUM 
token file a Fite 


SAMPLE. TEN AMP TEN 
source file : an aePus. < polished PG 


comment file comment file \ $SAMPLB. POL 


| ay 
error file OPTION STRING 


#SAMPLA. SER eummary report 
#SAMPLE. SUMPL 


aption file 
#SAMPLE. OPT 





bicgure 62.0 The Flows of ISTAN. 


d. The Operation of ISTAN 

As mentioned above, the operational procedures. 
for ISTAL are little different with the given specification 
[Ref. 14: pp. 8-16]. The author selected the options, and 
the results are illustrated by Appendix F. The summarized 
operational procedures are listed in Figure 8.11 and Figure 
8.12. After executing the first step correctly, the user 
must compile and link the instrumented source program. The 


following are needed : 
¢ $§ fortran SAMPLE. FTN 


=o Link SAMPLE. OBJ (or SAMPLE) 
= 5S run SAMPLE. EXE (or SAMPLE) 


diz 


The output of the above execution is shown by Appendix F. if 
recommend to use the ISTCE (Command Executor) for runninae 
the ISTAN. 


oer over to invoke the command executor) 
AN to invoke the ISTAN) 

Input token stream : #SAMPLE. TKN 

Input comment stream : #SAMPLE. CMT 

Output instrumented source code : #SAMPLE. FIN 
Output statement summary : #SAMPLE. SUM 

Output annotated token stream : #SAMPLE. ATKN 
Output annotated comment stream : #SAMPLE. ACMT 
Output summary file : #SAMPLE. SUMFL 

Options : RUNDATA='SAMPLE' 


<ISTAN Normal Termination> 


ce: 
OF (return to VAX/VMS system) 


<TIE : Terminated> 





Figure 8.11 Operation Procedures of ISTAN (first step). 
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S) SMI a; to invoke the command executor) 


ee: ISTCE SO | 
BL, to invoke the ISTPL (polish tool) ) 
Input token stream : #SAMPLE. ATKN 


(The token stream produced by ISTAN. ) 


Input comment stream : #SAMPLE. ACMT 
(The comment stream produced by ISTAN. ) 


Polish output : #SAMPLE. APOL 
Option file : (none) 


<ISTPL Normal Termination> 


fee : return to the command executor) 
a oF 1 EOninvexe tChew@iolAL, terminal 1/0) 


al : ISTAL prompt) 
OE TES 

al : 

FOLDING YES 

al.: 

ooo = #SAMPLE. APOL 


al : 
RUN = #SAMPLE. DAT 
(This file produced by the ISTAN option. ) 


evils xs 
ee = #SAMPLE. SUM 
al: , 
LISTING 
(The output of the LISTING command is Appendix F) 
al: 
SEGMENT = ?* 

(The output of SEGMENT = ?* is Appendix F) 
a: 
HOTALS = ?7* 

(The output of TOTALS = ?* is Appendix F) 
STATIC = TEST 

(The output of STATIC = TEST is Appendix F) 


a: 
DYNAMIC = TEST 
(The output of DYNAMIC = TEST is Appendix F) 


al : 
eentrol Z (CreeMrn tte tne wiolCr) 
<ISTAL Normal Termination> 
ce : 
OT (return to the VAX/VMS system) 


< TIE : Terminated > 


Figure 8.12 Operation Procedures of ISTAN (second step). 
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IX. EVALUATION 


A. COMPARE USER NEEDS TO TOOLPACK GOALS 

The characteristics of mathematical software (defini- 
tions, application domains, need for efficiency, development 
environment, portability) and a description of programmers 
of mathematical software were presented in chapter 5. One 
way to compare the user needs with TOOLPACK goals is to 
identify any discrepancies between the characteristics of 
typical users of TOOLPACK and the assumptions that the 
designers of TOOLPACK made about them. 

The TOOLPACK system assumes that users have a working 
knowledge of terms like "lexical analyzers","parsers", 
"table managers" and "report generators". As discussed in 
chapter 5 the typical programmer (of mathematical software) 
is not acquainted with these terms. The TOOLPACK documenta- 
tion does not include definitions for these terms, tutorials 
on them or even references into the computer science litera- 
ture to learn about them. The typical -programmer does not 
have the background to easily access the literature on these 
EODiICs: It will be necessary for the TOOLPACK documentation 
to close the gap between user needs and TOOLPACK goals by 
providing expository materials oon all the pertinent 
contents. 

In addition to specific concepts that are unknown to the 
typical user, the documentation contains phases and jargon 
from computer science that will be difficult for scientific 
programmers. It is probably not possible to remove all the 
technical terms from all the documentation, but the documen- 


tation could be improved greatly by identifying two distinct 


readers: 
1. typical users 
rae software experts 
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Each separate document could be designated for the typical 
user or for the expert (or perhaps installer). It would then 
be necessary for the user documents to systematically either 
remove or explain each technical term. 

One specified TOOLPACK goal was to provide "a structured 
Fortran language which enhances standard Fortran with modern 
control and data structures". The need for these capabili- 
ties is overshadowed by the need for code that can be easily 
debugged, tested and maintained. Since the inclusion of a 
production quality compiler is not a realistic goal, the 
TOOLPACK goal could be accomplished only with a preprocessor 
(like for example RATFOR). As discussed above, preprocessors 
have serious drawbacks including the inability to relate 
error messages to the source code. So although users do not 
need a preprocessor, the goal of providing better control 
and data structures than available in standard Fortran is 
foeortant. some capability for an improved language are 
provided by the non-standard extensions to Fortran that are 
unique for each computer manufacturer. TOOLPACK does not 
have a goal to support these computer unigue Fortran exten-~ 
Sions that help provide the modern features needed by 
programmers. 

The most serious gap between user needs and TOOLPACK 
goals is in portability. Although portability was only a 
very minor part of the original TOOLPACK goals [Ref. 1: pp. 
5-6] it achieved major status in the architectural design 
@eeument {Ref. 7r p. 3). Portability is only a secondary 
goal of the vast majority of scientific programmers; more 
important goals are runtime efficiency (including use of 
computer unique Fortran extensions) and high programmer 
productivity (use of simple, effective tools with low run 
time expense). Programmers would like to be able to move 
their code easily to other machines andto easily use 


programs produced on other computer systems but they 
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recognize that the main obstacle to portability is numeric 
precision. No goals of TOOLPACK (or any theory the author 
knows about) is going to solve the problem of moving high 
performance numerical algorithms from one computer to 
another computer that has a different model of real 
computation. It is possible to have portability for 
non-numeric algorithms (like TOOLPACK itself) but is a 
serious mistake to confuse the needs of NAG and the TOOLPACK 
developers for portability with the needs of TOOLPACK users. 

As discussed in chapter 5, most programmers of mathemat- 
ical software have a very limited domain of interest. They 
are interested ina limited set of software for a limited 
set of science, mathematics or engineering problems. They 
therefore need to be able to pick and choose the subset of 
TOOLPACK that best suits their needs. Also the suite of 
software tools that is provided by the computer manufacturer 
differs widely from machine to machine. Given a choice 
between a manufacturer provided tool (optimized to the 
machine, integrated with the compiler) and an equivalent 
TOOLPACK tool, most users will use the manufacturer supplied 
tool. Thus the TOOLPACK goals need to be subdivided into 
subgoals that will allow the user to pick, install and learn 
subsets of the total capabilities without commiting to a 


comprehensive environment. 


Se COMPARE TOOLPACK GOALS TO ITS CAPABILITIES. 

It is difficult to compare the TOOLPACK goals tomas 
capabilities because there seems to be two very different 
set of goals. The original goals of TOO@LPACK [Ref. 1: me 
5-6] seem to be focused on providing tools for the vast 
majority of mathematical software programmers that are 
described in chapter 5. As can be seen in chapter 4, the 
architectural design document [Ref. 7: p. 3] presents a 
different set of goals; if the phase "mathematical software" 


in goal 1 were changed to "non-numeric mathematical 
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software", the architectural design goals would be seen to 
lew fLocused on an entirely different set of users namely 
those producing software like TOOLPACK. 

Meswe accept the goals of Che architectural design, the 
capabilities of TOOLPACK version 1 fulfills most of the 
goals. For a user population with a strong computer science 
background in language translation the system capabilities 
are well understood, the terms in the documents are 
familiar, the heavy use of technical jargon makes the docu- 
ments appropriately terse, and the installation while need- 
lessly complex and ambiguous is within the skills of a good 
systems programmer who has two weeks to spend on what should 
be a one day job. The lexical analyzer, parsers, table 
manager, pretty printer all work well and the "tool frag- 
ment" design is well suited for those users who want to 
build their own non-numeric mathematical software. 

If we accept the original TOOLPACK goals the evaluation 
is very different. For the vast majority of programmers of 
mathematical software the capabilities of version 1 fall far 
short of the goals. Aside from enforcing the use of standard 
Fortran (the tools reject computer unique extensions and/or 
produce code that is incorrect), there is nothing that 
supports the portability of numeric software. As mentioned 
above, easy portability of numeric software is an unreal- 
istic goal, however, it is striking that there is no 
discussion andno system capability directed toward this 
important problem. 


The goal of a structured Fortran extension of standard 


Fortran was also abandoned. This was most likely a good 
decision; in the last several years there has been an 
increasing lack of enthusiasm for preprocessors. Likewise 


the automatic conversion of standard Fortran to structured 


Fortran is not a serious loss. 
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The capabilities for precision transformation, static 


and dynamic analysis tools, Fortran syntax editor, pretty 
printer and the language translation tools (lexical 
analyzers, parsers, etc) were achieved inversion l. These 


tools represent a real contribution to the programmer that 
knows how to use them. 

An important and dominant capability that is not explic- 
itly mentioned in the goals is the file handling and control 
environment that comes with TOOLPACK. The author used only 
the STAND-ALONE mode of operation for several reasons: 


1. The VAX/VMS system already has a good modern file 
system. : 


Zz. The focus of the evaluation was on tools rather than 
environment. 


3. The installation of even the STAND-ALONE took so much 
longer than planned (months instead of days) that 
there was not time to evaluate other modes. 

Despite the lack of direct evaluation, the author feels that 
there is little in the other modes of operation that justify 
the cost and effort of learning and installing them. Given 
that the typical programmer wants to maximize his use of the 
manufacturer supplied tools and given these are good (like 
on the VAX/VMS), there is little incentive to use the 


TOOLPACK file structure or command features. 


C. COMPARE USER NEEDS TO TOOLPACK CAPABILITIES. 

As discussed above, the human factors associated with 
software products are important. Mathematical software 
programmers are also not eager to learn new systems with new 
messages and error reports. The author feels that the 
TOOLPACK error messages are unsatisfactory. The following is 


an example of TOOLPACK error messages: 


C*PL*ERROR Unexpected Statement type 
C*PL*ERROR Unexpected <TZOES> 


C*PL* ERROR Internal Error (CGCRINDI) = IZEOS contusrem 
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These messages, produced by ISTPL (the polish tool), 
resulted from not defining a subprogram name in the declara- 
tion part of a program. These messages don't help the user 
identify the error. TOOLPACK needs to develop and use a more 
clear error reporting system. 

The TOOLPACK project consists of 33 tools. The author 


thinks that most mathematical programmers won't use all 


these tools. They will select the tools which are most 
convenient and helpful to them. Some tools will never be 
used by mathematical programmers. For example, various 


computer systems have their . own editor system (1i1.e., 
IBM: XEDIT, VAX/VMS: EDIT, and UNIX system :VI editor). These 
editors are already familiar to its users and the users are 
skilled in their editor systems. The author, therefore, 
thinks that mathematical programmers will use their own 
editor system rather than ISTED (editing tool) which is 
provided by the TOOLPACK project. 

The author suggests that the TOOLPACK project should 
concentrate on suitable tools rather than unused tools, SO 
that the quality of tools will be more powerful than previ- 
ously distributed tools. The author recommends that ISTPL, 
ISTPT, ISTAN, and ISTAL are very useful tools. 

It is very hard to install TOOLPACK. Today most software 
packages are not very hard to install in their own computer 
systems. Generally speaking, even though the users are not 
specialists in the software packages, if they follow the 
given manual then they can easily install the package. 

Sometimes, if the software packages are difficult to 


install then the company of the distributed program makes 


available installation services and/or good manuals. The 
author understands that the TOOLPACK project is not a 
commercial operation, but the installation guides (for 


example: TIE code installer's guide and Tool installer's 


guide) are not very easy to read and understand. Another 
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thing is that to understand the TOOLPACK installer's guide 
the reader needs a background of computer architecture and 
operating systems. The author spent 4 months to install the 
TOOLPACK with help from our computer center staff. There is 
an immediate need for a tool to help TOOLPACK users install 
and test the system. 


D. COSTS VEKSUSSERIErins 

The system resources needed by TOOLPACK version 1 are 
considerable. The memory requirements are significant, this 
would have major impact for small computer systems. The 
details of memory requirements are shown in Figure 9.1. 

The cost and effort involved in initially constructing 
the tools are significant. Any modification of the programs 
involves significant effort and modifications in the library 
routines involves significant work. These jobs are all 
tedious and time consuming and are well beyond the patience 
of a single mathematical software programmer. They can only 
be justified if many people are using the system. The poten- 
tial user population is reduced significantly if use is 
restricted to installations with a systems programmer who is 
responsible for installation and maintenance. 

The benchmarks in chapter 8 show that CPU times are very 
large for even medium size programs. This will surely drive 
users to using software provided by the computer manufac- 
turer whenever possible. In particular, the users are likely 
to use file handling and control features that are provided 


more cheaply on their computer. 
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Memory spaces of each tool. 
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X. CONCLUSIONS 


One notable lack in the TOOLPACK project is a comprehen- 
sion user profile that would describe the user's needs, 
capabilities and potential for learning new ideas. A well 
Known tenet in software engineering is that in the absence 
of good user requirements, designers and implementers use 
themselves as a model of the user. On several issues, most 
notably portability, the TOOLPACK goals and capabilities are 
heavily skewed towards users who are -producing non-numeric 
software to be distributed (NAG and the "PACK" developers) 
and away from users who are writing numeric software for 
their own use. 

The vast majority of mathematical software programmers 
are producing software for their personal use. They have a 
strong preference for using software tools that are provided 
by the manufacturer of their computer because these tools 
are very efficient and are (and will continue to be) inte- 
grated with the Fortran compiler and its computer unique 
extensions. 

For these users, TOOLPACK provides capabilities that are 
not currently available on their computer; they are more 
interested in picking and choosing specific tools than in 
learning (another) total environment. Another (but 
different) set of users is interested in producing portable 
numeric software for general use, in the author's opinion 
they are better served by having tools that help them 
customize software to different environments (1. eae 
machines, compilers) rather than build software for a stan- 
dard environment that is not likely to be widely accepted by 
the vast majority of mathematical software programmers. 

A third (and very small) set of users is interested in 
producing non-numeric software (e.g., TOOLPACK) for general 


use. 
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For these users (unlike the others) pereabialieyeis — both 
technically possible and economically desirable. While 
waiting for their computer manufacturer to produce new tool 
X, these users are quite willing to pay the run time cost of 
using portable tools if they are not forced to pay a heavy 
cost to install and are not forced to use a new comprehen- 
sive environment. 

In conclusion, the capabilities of TOOLPACK release 1 do 
Meee fulfill the original goals of supporting scientific 
programmers in the construction of numerical software. The 
system is much too hard to install, demands the user accept 
a new environment and does not make effective use of 
computer resources. The fundamental problem with the system 
is that it has been driven entirely by the goal of producing 
a portable environment=- this is not a major need of scien- 
tific programmers. It is difficult to see how modifications 
of the present system can lead to a system that will meet 
user needs, it appears that a major rethinking of goals is 


required. 
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APPENDIX A 
VAX/VMS COMMAND FILE (EXAMPLE FOR BENCHMARK TEST) 


! 
5; TSTexX. Come command file to execute ISTLX 


TIESERROR =u" 


hs P1.EQS." " THEN INQUIRE Pl "NAME OF THE FORTRAN FILE" 
SHOW SYSTEM 


ISTLX #/B1,.EOR #'P1'. LIS #'P1'. ERR #'P1'. TKN 
pia TIESERROR . EQS. "ERROR" THEN EXIT 
SHOW SYSTEM 
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a. Pope 





we. COM : 





APPENDIX B 
USEFUL COMMAND FILES 


Command file to execute the ISTDC 


ec ce one parameter, the file name of the Fortran 
file with no extension 


PREREQUISITES : NONE . 

NOTE > JReehtatiemert —EeaceoucputL efile as DIFF. LIS 
_TIESERROR="" 
‘IF Pl .EQS. "" THEN INQUIRE Pl "Name of Standard File" 
,IF P2 . EQS. "" THEN INQUIRE P2 "Name of Comparison FIle" 
PUSTDC #'P1'. FOR #'P2'. FOR #DIFF. LIS 

IF TIESERROR . EQS. "ERROR" THEN EXIT 

2. ISTED 

FD.COM : Command file to execute the ISTFD 


ane one parameter, the file name of the Fortran 
file with no extension 


PREREQUISITES : NONE 
_TIE$ERROR="" 

marl .e0S. "" THEN’ INQUIRE Pl “Name gt First Token 
IF P2 .EQS. "" THEN INQUIRE P2 “DERE Fe Second Token 


“ISTFD #'P1'. TKN #'P1'.CMT #'P2'. TKN #'P2'. CMT 
Peis 11S 


IF TIESERROR . EQS. 


"ERROR" THEN EXIT 
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FP.COM : Command file to execute the ISTFP 


t 
f 
! 
' This tool is the fast polish program (Within the 
GENERAL tools). 
t 


PREREQUISITES : ISTLX : 
_TIESERROR="" 
is Pl .EQS. "" THEN INQUIRE Pl "Name of Fortran File" 


! 
ISTLX eras #'P1'. LIS #'P1'. ERR #'P1'. TKN 
IF TIES$ERROR .EQS. "ERROR" THEN EXIT 


ISTEP #'P1'. TKN #'P1'.cMT #'P1'. OUT 
IF TIESERROR .EQS. "ERROR" THEN EXIT 


4. ISTLX 





LX.COM : Command file to execute the ISTLX 


Expect one parameter, the file name of the Fortran file 
with no extension 


——B 6-8 +-8 Com seem =] O-w 8 = 


PREREQUISITES : NONE 
_TIESERROR="" 
7s Pl .EQS. "" THEN INQUIRE Pl "Name of Fortran File" 


ISTLX #,£1,- FOR #'P1'. LIS #'Pl’ ERRee ft oeee DK 
e TIESERROR . EQS. "ERROR" THEN EXIT 
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5. ISPeL.( simple Method) 


PLI.COM : Command file to polish a single file of 
Fortran-/7 code 


PREREQUISITES 3: )9lstix 


NOTE : This command file doesn't use the tools which 
are ISTYP and ISTDS. Therefore, the output is 
less readable than the other output which uses 
the ISTYP and ISTDS. If the user _wants to use the 
option file then this command file needs 
minor correction which is to append the option 
te lev ethat 2s get from the tool ISTEPO. 


_TIESERROR="" 
a Pl .EQS. "" THEN INQUIRE Pl "Name of Fortran File" 


ISTLX #,51,- OR + Pie oe bleeERR #' Pl’. TAN 
IE TIESERROR .EOS. "ERROR" THEN EXIT 


Peete el TKN 6# Pl. CMT #P1'. POL 
IF TIESERROR .EQS. "ERROR" THEN EXIT 


6. ISTPL (Complex Method) 


PL2Z.COM : Command file to polish a single file of 
Fortran-/77 code 


EeSREQUISITES : ISTLX,ISTYP, and ISTDS 


NOTE : This _ command file uses the tools which are 
toive and IsTbs. Themezore, the output is more 
readable than the other output which doesn t use 
the ISTyYP and ISTDS. If the user _ wants to use the 
Option file then this command file needs a . 
Memor COLrrectlon which is to ae tie: the option 


Pole that 1s get Lrom the tool ISTPO. 
_TIESERROR="" 
18g Pl . EQS. "" THEN INQUIRE Pl "Name of Fortran File" 


' 

ISTLX fee LOR i? Pl Eocene a Pl’. TKN 
IF TIE$ERROR .EQS. "ERROR" THEN EXIT 

ISTYP #\21,. TKN #'P1'.CMT #'P1'.TRE #'P1'. SYM 
IF TIESERROR .EQS. "ERROR" THEN EXIT 

BisiDo # P1'. TRE #'Pl'. SYM #'P1'. TKN #'P1'.CMT 

PT  #LP i! M2 
IF TIE$ERROR .EQS. "ERROR" THEN EXIT 


“ISTPL (#'P1'. TKN #'P1'.CMT #'P1'. POL 
$ IF TIE$ERROR .EQS. "ERROR" THEN EXIT 
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7 ISTPI (Simple Method) 


PT1.COM : Command file to Preciclon=s tranareri 240mm 
single precision file ,etePortman-/7 sovece 
to double precision file of Fortran-77 
source code. 


PREREQUISITES : ISTLX (lexical analyzer) 
Sire Gearsen) 
Sage ets see transformer ) 
Ledge lt olis 
Pdefault options are none) ) 


NOTE : This command file doesn’t use the LOOL, whieh 
is the ISTDS. Therefore, the output is less 
readable than the other output which uses the 


ISTDS. 
_TIE$ERROR="" 
oe: Pl .EQS. "" THEN INQUIRE Pl "Name of Fortran File" 


" ISTLX i ,52,- EGR #"P1'. LIS $° Pigs te ed nian 
_IF TIESERROR .EQS. "ERROR" THEN EXIT 

LS a4e #, £1). TKN #'P1'.CMT #'P1'.TRE #'P1'. SYM 
_IF TIESERROR .EQS. "ERROR" THEN EXIT 

TS TD Eee een ete Bly. SYM #'P1l'.CMI #'P1'.CMT 


oTK2Z eet M 
IF TIESERROR eee "ERROR THEN EXIT 


’ ISTP qeP he TK +) Pl’. CMT #'P1’. Pol 
IF TIESERROR . EOS. ERROR THEN EXIT 
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8. ISTPT (Complex Method) 


Poze cOM :Gemmand Lile to sPrecision=transform from a 
single precision file of Fortran-77 source 
to double precision file of Fortran-77 
source code. 


PREREQUISITES : ISTLX (lexical anayzer) 
ISTYP (parser) 
ISTDS (declaration standardizer) 
ISTPT (precision transformer) 
TSirG olish) 
i (deme options are none) ) 


NOTE : This command file uses the tool which is the 
[ISTDS. Therefore, the output is more readable 
than the other output which doesn t use the ISTDS 

, TIESERROR="" 


“IF Pl .EQS. "" THEN INQUIRE Pl "Name of Fortran File" 


ISTLX #,B1,- FOR #'P1'. LIS #'P1'. ERR #'P1'.TKN 
IF TIESERROR .EQS. "ERROR" THEN EXIT 
MotrP 4 Pl .TKN #'P1'.CMT #'P1'.TRE #'P1'.SYM 
IF TIESERROR . EQS. "ERROR" THEN EXIT 
ISTDS #,51,- TRE EBL" Guo forthe Pl CMT 
IF TIESERROR .EQS. "ERROR" THEN EXIT 
Bory? #,B1,. 2K2 oP SeMQm Piet RZ PL. SM2 
IF TIESERROR .EQS. "ERROR" THEN EXIT 
BoTeT een Bo ea SM2 #'P1'.CMI2 #'P1'.cCM2 
IF TIESERROR . EQS. "ERROR: THEN EXIT 


ISTPL #' Pl’. TK3 CM3_#'P1'. POL 
IF TIESERROR . EQS. FHERROR THEN EXIT 
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9. seer 





TD.COM : Text Differencer 
(This is the standard text differencing tool) 


expects one parameter, the file name o£ Gabe Fortran 
file with no extension 


PREREQUISITES : Views 


-<—— Comm Oca CoD OC CGR Oo OC 6 om 6 om 


_TIE$ERROR="" 

“IE Pl .EQS. "" THEN INQUIRE Pl "First Input File" 
TE P2 .EOS. "" THEN INQUIRE P2 "Second Input File" 
-ISTTD #'P1'. FOR  #'P2'. FOR 

IF TIESERROR .EQS. "ERROR" THEN EXIT 


TOP oy 


VS.COM : Command file to execute the ISTVS 


ripe one parameter, the file name of the Fortran 
file with no extension 


PREREQUISITES : ISTLX, ISTYP 
_TIESERROR="" 
IE Pl .EQS. "" THEN INQUIRE Pl "Name of Fortran File” 
ISTLX #,51,-ZOR #'P1'. LIS #'P1'. ERR #'P1'. TKN 
_IF TIE$ERROR .EQS. "ERROR" THEN EXIT 
ESN ge #,21,. ZEN +'Pl'. CMT #'P1'. TRE “# Pi’) oun 
IF TIESERROR .EQS. "ERROR" THEN EXIT 


ISTVS #'Pl'’.SYM_ #/)P1'. LIS HEAD 
IF TIESERROR .EQS. "ERROR" THEN EXIT 


eel 


C-—— $258 €o=b Cogn @€°=R ¢25P CoRR Com 


IE Pl 


BusTY? #'DI' TRE #'P1'. SYM #'P1'. CMI #'P1'. 


11. 


Co nye 


YF.COM : 


a cme: one parameter, 
e with no extension 


Command file to execute the ISTYF 


BeeooulS Teo: ISsthe, ISTYP 
, TIESERROR="" 


5 OSE 


the file name of the Fortran 


"" THEN INQUIRE Pl "Name of Fortran File" 
eESTLX #'Pl'. - EOR 7 Pi. DiS Pie BRR +7 Pd 
we TIESERROR’ EQS. "ERROR" THEN EXIT 
" ISTYP #,51,- TKN fee CM HePl ERE +) Pl" 
_IF TIESERROR . EQS. "ERROR" THEN EXIT 


‘IF TIESERROR . EQS. "ERROR" THEN EXIT 


=m Comb 9S G25 ¢2-5R Come CO Cou 


AZ 


YP.COM : 


SY a 





Command file to execute the 


oh 


ee oul 


CMT #YF. TKN 


ISTYP (Parser) 


expects one ‘parameter, the file name of the Fortran 
file with no extension 


PREREQUISITES : ISTLX 
, TIESERROR="" 

lf Pl 
ISTLX cae SOR #'P1'. LIS #'P1'. ERR #'P1' 
,1F TIE$ERROR .EQS. "ERROR" THEN EXIT 

" ISTYP Hoel. i - TKN ie emer iieer ll ERE at! Pi! SYM 
9 TIESERROR EQS. "ERROR" THEN EXIT 


. EQS. 


Sie 


"" THEN INQUIRE Pl "Name of Fortran File" 
. TKN 


APPENDIX C 


THE RESULTS OF RUNNING IN ISTPL 


le The Source Program for Testing 


PROGRAM TEST 
INTEGER eo! NEVEN, ND3 

REAL SUM, RESULT  _ ) 

WRITE(* *) Please input ten integers : 
READ( *, X 


100 


150 FORMAT( 


WRI Be 160) eee 
160 FORMA (2x None were divisible by 3.) 

ELSE I ( ESULT. EQ.1) THEN 

WRITE ) 


Lge: EORMA (2X, ‘One was divisible by 3."') 


WRITE ee) RESULT a ; 
180 SEE EA ee fee were divisible by 3.) 


REAL FUNCTION SUM(A,N) 
INTEGER N,A(N),1 


| =e ih 
100 SUM = SUM + A(I) 
END 


INTEGER FUNCTION NEVEN(A,N) 
INTEGER N, A(N),I 
NEVEN = 0 
DO 100 I =1,N 

100 NDE (MOD( A(1),2).EQ.0) NEVEN = NEVEN + 1 


INTEGER FUNCTION ND3(A,N) 
INTEGER N,A(N),I 
ND3 = 0 
DO 100 I=1, N 
100 a IF (MoD(A(1I),3).EQ.0) ND3 = ND3 + 1 


=) 


Zz, the Output of Polished Program( Simple Method) 


PROGRAM TEST 
INTEGER X(19) NEVEN, ND3 
REAL SUM, RESULT 


WRITE (* eit input ten integers : 


READ 
RESULT = M( X Oi. 
WRITE (*, 100 kes Aly 
100 FORMAT (2X, 'The sum is:', F7.2) 
RESULT = NEVEN( X £29) 
WRITE (*, 150) RESULT 
150 FORMAT (er. ID jf 4 2a ' of them were even.') 
RESULT = 
IF ( RESULT. TBO, oh HEN 
WRITE (* 
160 FORMAT eras "None were divisible by 3.') 
ELSE IF (RES EQ.1) THEN 
WRITE (*,1 
170 FORMAT (2X, Au was divisible by 3.') 
ELSE 


Writes SO) RESULLE 
180 FORMAT(2X, F7.2,' were divisible by 3.') 
END IF 


SOP 
END 


REAL EUNCTION SUM(A,N) 
INTEGER N,A(N), 


SUM = 0 
Demoo FT = 1, N 
100 SUM = SUM + A(T) 
END 


INTEGER FUNCTION BD ea N) 
INTEGER N, A(N), 


NEVEN = 0_ 
DO 100 
100 TE (MOD(A( I)’ 3). EQ.0) NEVEN = NEVEN + 1 


INTEGER FUNCTION ND3(A,N) 
INTEGER N,A(N), 


ND3 
DO 100 
100 IF (MOD(A( I). 3). EQ.0) ND3 = ND3 + 1 
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3 The Output of Polished Program( Complex Method) 
PROGRAM TEST 


C .. lbeocal Scalaws. 
E REAL RESULT 
C . Local Arrays .. 
e INTEGER X( 10) 
e ..External Functions .. 
REAL SUM 
INTEGER ND3, NEVEN 
i EXTERNAL SUM,ND3, NEVEN 
WRITE Bt: *) ‘Please input ten integers :' 
READ D ats 
RESULT = 00) * ee 
WRITE (*,100) RESULT 
100 FORMAT (2eeeiie lsum iS 27) yay 
RESULT = NEVEN( X 19) 
WRITE (*, 150) RESULT 
iS oe (2%, F7. ah ' of them were even. ') 
IF (RESULT, T ROS oh dren 
WRITE (*, 
160 FOR one were divisible by 3.') 


™N 
ELSE IF re EQ. 1) THEN 
WRITE (*,170 


170 FORMAT (2X, oe was divisible by 3.') 


LSE 
WRITE (*,180) RESULT 
180 FORMAT(2X, F7.2,' were divisible by 3.') 
END IF 


SLor 

END 

REAL FUNCTION steten EE SY 
Scalar Argumen 

INTEGER N 


ray ane uments .. 
LirEGER ACN 


Local Scalars .. 
INTEGER I 


SUM = O 
100 I =1, N 
100 SUM = suM + A(T) 


C2201. "OOO 


histo FUNCTION NEVEN( A,N) 
Scalar Arguments .. 
INTEGER N 


Avan treks 7 
rien BEER” A(N) 


Local Scalars .. 
INTEGER NE 


OQ 20) (OO © 


che: 


0 40 €02 ©) 


100 


100 


WeEneESInsic Functions 
INTRINSIC MOD 
NEVEN = 0 
100 I = 1,N 
A(I),2).EQ.0) NEVEN 


INTEGER FUNCTION ND3(A,N) 
scalar Arguments .. 
INTEGER N 


Arguments .. 
riemBEER’ ACA 


Local Scalars .. 
INTEGER I 


Waeimeriasite Functions .. 
INTRINSIC MOD 
ND3 = O 


DO 100 I = 1, N 
TF (MOD(A(T),3).EQ.0) ND3 
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= NEVEN + 1 


= ND3 + 1 


4. The OQutput of Polished Program( With Errors 


PROGRAM TEST 
. Local Scalars .. 
REAL RESULT 


Local Arrays .. 
INTEGER rei IO) 


.External Functions . 
C*PL*ERROR* Unexpected statement type 
C*PL*ERROR* Unexpected <TZEOS> 
SUMINTEGER ND3, NEVEN 


NO OG 


C*PL*ERROR* Internal Error CoAT Ned) - TZEOS confusion 


EXTERNAL SUM,ND3,NEVE 


WRITE (a *) 'Please input ten integers : 
READ : a 

RESULT = 2), 

WRITE (*, 100 “RES CHL 


100 FORMAT (2X, ‘The sum is :', F7.2) 
RESULT = NEVEN(X,10 
WRITE (*, 150) RESULT 


150 FORMAT Cre. aps a8 ' of them were even. ') 
RESULT = 
IF ees 2 of HEN 
WRITE (*, 


160 FORMA Sars 'None were divisible by 3. 
ELSE IF (RES ULT. EQ, 1) fen 
Wikene(e* 1 7 e 


170 FORMAT (2X, - was divisible by 3.') 


C 


LSE 
WRITE (*,180) RESULT 
180 FORMAT( 2X, F7.2,' were divisible by 3.') 
END IF 


SLOP 

END 

REAL FUNCTION De 
. scalar Arguments . 
INTEGER N 


rray Arguments .. 
vier ACRT? 


Local Scalars .. 
INTEGER I 


Q QQ QQ © 


100 SUM = SUM + A 


INTEGER FUNCTION NEVEN(A,N) 
scalar Arguments .. 
INTEGER N 


. Array Arguments .. 
INTEGER A(N) 


Local Scalars .. 


COCO) “C2 
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QQ Ad QQ a 


100 


100 


TEER I 


Pherbainsic Functions .. 
INTRINSIC MOD 


NEVEN = 0 


POr7oo. | iON 


IF (MOD(A(I),2).EQ.0) NEVEN 


INTEGER FUNCTION ND3(A,N) 
scalar Arguments .. 
INTEGER N 


Arguments .. 
vimmBBERY CRT” 


~mgeeeocal Scalars. .. 
INTEGER I 

Mmeimirinsic Functions .. 
INTRINSIC MOD 

ND3 0 

DO 100 I = 

Lae (MODCAC LY! ea EQ.0) ND3 
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-_—= 
— 


= NEVEN + 1 


ND3 + 1 


Se 


QQ QQ 0 


©) 


WOWwWww 
OO0O00 
H> WN © 
OO0O00 


QQ QQ QQ 


Q 


100 


QQ QQ aq a 


The Output of Polished Program 


(With Selected Options) 
PROGRAM TEST 
Local Scalars .. 
REAL RESULT 


Local Arrays .. 
INTEGER X( 10) 


_. External Functions .. 


) 


. 


REAL SUM 
INTEGER ND3 VEN 
EXTERNAL SUM, NDS. NEVEN 
WRITE (a 'Please input ten integers : 
READ f x 
RESULT = aca ae 
WRITE (*,900 d RESULT 
RESULT = NEVEN( X rer 
ITE (*, 9010 RESULT 
RESULT = ND3(X ree 
IF (RESULT. E 0) HEN 
WRITE (*,9020) 
ELSE IF eG E eeheve ci 
Rik ( 9030 
ELSE 
WRITE (*,9040) RESULT 
ENDale 
STOP 
FORMAT (2X, =ahs Sunes le eeh ee 
FORMAT (2X, F7.2, ae them eee 3, 
FORMAT (2X, None were Sie 
FORMAT (2X, One was divisible 
oa i eee, were Sigieione 3. 


REAL FUNCTION coin ea 
. scalar Argumen 
INTEGER N 


Arguments 
ees A 


Local Scalars .. 
INTEGER I 
SUM = 0 
DO 100 I =1, N 
SUM = SUM + A(T) 
END 
INTEGER FUNCTION eae N) 
scalar Arguments . 
INTEGER N 


Array Ar 
INTEGER A( 


Local Scalars .. 
INTEGER I 


[REE In Siles Functions... 


ae 
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' 


) 


WWWWWWWNNNNNNNNNNHHBHHH HEHEHE 


HMHOWONOUBRONH HUPWNHOUWUOAIOUBRONH OUBPWONHOUDOATIOUBWONHOUONOUTBWONHOWOWNOUBWNEH 
ODDO OOOO OOOO OO OOO OO OOOO OO OO OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOCOOOO0O00O 


eed ele 


pops 


QQ QQ QQ 0 


100 


100 


INTRINSIC MOD 
NEVEN = 0 


ber too 1 = 1,N 
TF (MOD(A(I),2). EQ. 0) NEVEN 


INTEGER FUNCTION ND3(A,N) 
.. Scalar Arguments .. 
INTEGER N 


.. Array Arguments .. 
INTEGER A(N) 

.. Local Scalars .. 
INTEGER I 

-. Intrinsic Functions .. 
INTRINSIC MOD 
NbD3.=.0 


DO 100 I =1, N 
TF (MOD(A(1),3).EQ.0) NDS 


100 


= NEVEN + 1 


Nes + 1 


yee 
OU BPWNRPOWOWNOAUBPWNHR SIOUTBPWLD 


ODD DVDODOOODOQVOOVOO OO 9OO000O 


eee eer 


100 


150 


160 


aA, 


180 


THE RESULTS OF RUNNING IN ISTPT 


The Output of Precision Transformation 


(Simple Me 
PROGRAM TEST 


APPENDIX D 


thod) 


INTEGER K( 10) NEVEN, ND3 
et one 


DOUEBLE PR hNecoUM, RESULL 

WRITE arr *) ‘Please input ten integers : 
READ ; 

RESULT = aoe = 

WRITE (*,100 bes Jeay 

FORMAT (2X, ‘The sum is :', F7.2) 


RESULT = NEVEN( X,10 


RITH(* aoe 


FORMAT (2X, F7. 26 
RESULE = 120, 
IF ( RESULT E 3}. 


Rare % 
FORMAT (2X 
ELSE IF (RES igh 

WRITE (*,1 
FORMAT (2X, - 
ELSE 


WRITE (*,180 


FORMAT( 2X, F7.2,' 
END IF 


SOE 
END 


ESULT 


of them were even. ' ) 


SHEN 


'None were divisible by 3. 


EO.1) THEN 
was divisible by 3.') 


) RESULT 
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were divisible by 3. 


') 


') 


DOUBLE PNA 


Dea FUNCTION SUM(A,N) 
INTEGER N,A(N),I1 


SUM = 0 
Denice. = 1, N 
100 SUM = SUM + A(I) 
END 


INTEGER FUNCTION NEVEN(A,N) 
INTEGER N, ACN), 


NEVEN =_0_ 
Domne On | 
100 ao (MOD(A(1)_ 2). EQ.0) NEVEN = NEVEN + 1 


INTEGER FUNCTION ND3(A,N) 
INTEGER N,A(N),1 


ND3 = 0 
Dorioe.1 —"1 
1E (MO 


,_N 
100 D(A(1),3).EQ.0) ND3 = ND3 + 1 
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Ze The Output of Precision Transformation 
(Complex Method) 
PROGRAM TEST 


cS Local Scala 

~ DOUBLE PRECTSION " RESULT 

‘Se Local Arrays .. 

. INTEGER X( 10) 

CG _Exte rnal Functions .. 
DOUBLE PREIESION SUM 
INTEGER ND3, NEVEN 

2 EXTERNAL SUM, NDS NEVEN 


WRITE ae 1 "Please input ten integers : ' 
READ ; 

RESULT = o 

WRITE (*, 100 RES ak 


100 FORMAT (2X, 'The sum is :', EF7.2) 
RESULT = NEVEN( X 10) 
WRITE (*, 150) RESULT 


150 FORMAT nb Ae 4 " of them were even. '') 
RESULT 
IF ( RESUL De 523, HEN 
WR ITE. Cx. 
160 FORMAT eas 'None were divisible by 3.') 
ELSE IF (RES aa EQ. 1) THEN 
WRITE (*, 


170 FORMAT (2X, 'One was divisible by 3.') 


LSE 
WRITE (*,180) RESULT 
180 FORMAT(2X, F7.2,' were divisible by 3.') 
END IF 


Ser 
END 
DOUBLE PRECISION FUNCTION SUM(A,N) 


. scalar Arguments .. 
INTEGER N 


Arguments .. 
rim BEERY ACS 


Local Scalars .. 
INTEGER I 


Q QAQ QQ OE 


SUM = 0 
BO 100 1 

100 SUM = SUM + 44) 
END 


INTEGER FUNCTION NEVEN(A,N) 
Scalar Arguments .. 
INTEGER N 


Ar Arguments .. 
rieneeay A (NM) 


Local Scalars .. 


QQ O20 0 


103 


QQ aAQ AQ a 


OC 


100 


ERE ER I 


Neminioke FUNCTIONS .. 
INTRINSIC MOD — 


NEVEN = 0 
DO 100 I =1,N 

IF (MOD(A(1I)/2).EQ.0) NEVEN 
END 

INTEGER FUNCTION ND3(A,N) 


Scalar Arguments .. 
INTEGER N 


Array ments .. 
INTEGER Y ACN Ny 


Local Scalars .. 
INTEGER i 


Bitrans.e Functions .. 
INTRINSIC MOD 
ND3 = O 


TF (MOD(A( LY 3) EQ.0) ND3 
TF /3). EQ. 
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= NEVEN + 1 


= ND3 + 1 


APPENDIX E 
THE COMMANDS AND OUTPUTS (ISTAL) 


1. ISTAL COMMAND 
This appendix contains a quick reference guide to the 
commands available in ISTAL. 
The following commands control the general operation 
of 1STAL: 


¢ DEbug (=YES/NO) 
¢ FOlding (=YES/NO) 
e Intrinsics (=YES/NO) 
¢ Verbose (=YES/NO) 


The following commands are based on the use of 
information from ISTYP format symbol tables: 


¢ CAllgraph (= #file name) 
¢ COmmon (= #file name) 
¢ FUllxreference (= #file name) 
e SYmbol (= expression) 
¢ TAble (= #file name) 
e Warning (= expression) 
¢ Xreference (= #file name) 


The following commands are based on the use of 
information derived either from the analyzer(ISTAN) or the 


results of an instrumented run: 


e ANnotated (= #file name) 
¢e Run time (= #file name) 
e SUmmary = #file name) 
e ASsertions (= expression) 
© Eiseing (=no<list>) 

e SEgments (= expression) 
e STatic (= expression) 
¢ TOtals (= expression) 


iOS 


Z. Qe ovutputeo ALLGRAPH 


The following callgraph shows the routine dependencies 
of those routines and entry points detailed within the 
specified symbol table files. 


Where an entry is followed by a number in brackets, the 


number refers to the line on which that entry's 


expansion has already been shown. 
Question mark, this indicates that the routines symbol 


tables was 126 provided. 





cm The output of COMMON command 





The following table details the usage of common blocks 










within the specified symbol table files. 
Each common block is given, followed by the name of the 
block data program 3 it appears in (if relevant). 
Scommon is unnamed common, 
SBLOCKDATA is unnamed block data. 


There are no common blocks used. 


al : 
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4. The output of WARNING command 


The following table shows warnings drived from the 


symbol tables of the specified program units. 


Warnings for program unit : STAND 
Untyped Variable : I 





53 The output of SYMBOL = TEST command 


The following table shows the symbol usage for the 


specified program units. 


symbol table information for programeunleG << Test 
Variables : 
A - REAL Sc Selle la as an array) 
EXD lew e ay ee 
In READ input list 
Used as an actual argument 
In an expression 
X = REAL 
Assigned to on LHS of "=" 
In a expression 
Procedures 
MEAN 


- REAL 
ae licitly typed 
led as a function 


"2 an ex ression 
SQUARE _- Routine 
Called as a subroutine 
Pee - REAL 
2 ee ee I. 
led as Wc C1 om 
Th a tee Eeo = Ten 


Explicitly “ypss 
led as metLon 
Te an expression 


SUM 
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6. he output of SYMBOL = STAND command 


The following table shows the symbol usage for the 


specified program units. 


symbol table information for program unit : STAND 
Variabl : 
declared as an array) 
paeneL er 
Explicitly typed 
Used as an actual argument 
In an expression 
INTEGER 
fimanee press Oh | 
Used as a DO-loop index 
Explicitly typed 
gol Bal (ezat e 
Assigned 6 oh EHS of w=" 
In an expression 
INTEGER 
neta (paoaeees 
Explicitly typed 
Used as an actual argument 
In an expression 
Procedures : 
MEAN - REAL 


led as a nee. on 
Peat bes St Onl 
SIQUSIS Eejoeng altel 
Sedhicapa Iherl oo) curunc Ct On 
Called as a function 
In an expression 


Bee Ge cal pis 
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de The output of XREFERENCE command 


“The following sub-section show the routine dependencies 
of those routines and entry points detailed within the 
specified symbol table files. 
TEST 
NOT CALLED 
MEAN 
CALLED BY: 
TEST, STAND 
SQUARE 
CALLED BY: 
TEST 


STAND 
CALLED BY: 
Aga Sue 


SUM 
CALLED Bz: 
TEST 


SORT 


CALLED BY: 
STAND 





al 
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8. the output of FULLXREFERENCE command 


The following sub-section show the routine dependencies 
of those routines and entry points detailed within the 
specified symbol table files. 


Ia Syy 


CALLS: 
ME 
NOT CALTED 


SQUARE, STAND, SUM 


CALLS NOTHING 
CALLED BY: 
TEST, STAND 


SQUARE 
CALLS NOTHING 
CALLED BY: 
TEST 


CALLS 


MEAN, SORT 
CALLED BY: 
TEST 


CALLS NOTHING 
CALLED BY: 
TESL 


Standard Intrinsic} 
ALLED BY: 
STAND 





1 ALO) 


dig 


100 


100 


100 


100 


APPENDIX FE 
THE OUTPUTS OF IsiAn 


Fortran- SOURCE PROGRAM 


PROGRAM TEST 
REAL A( 10 7) ee N ae STAND 
PRINT *, ‘This 

Pee Ne Pilea eee 


READ * 

X=MEAN( A, 10) ; 

PRINT The mean 1s: ,xX 

X=STAND 

PRINT 'The standard deviation is : 
CALL TSQUAREC A, 10) 

PRIN The square of the numbers 
X=SUM( A’ 

Jeyee il ab 8) sum of the squares is: 
X=STAND D(A, 1 

PRINT fee standard deviation is: 
STOP 

END 

SUBROUTINE SQUARE(A,N) 

REAL A(N 


INTEGER N 


ACI) SACI)’ Aa) 
Abt INtE 

RETURN 

END 


REAL FUNCTION SUM(A,N) 
REAL et 

INTEGE N 

SUM=0 

DO 100 I=1,N 
SUM = SUM 


+ A(T) 
CONTINUE 
RETURN 


END 
REAL FUNCTION MEAN(A,N) 
REAL A(N) 
MEAN=0 

DO 100 I=1,N 
MEAN=MEAN/N 

END 


REAL FUNCTION STAND(A,N) 
REAL A(N 
aere 


STAN 
DO 100 = 
STAND= STAND+( A(T) =M) **2 


FPNERERS GS Beaton 


BREE! 


sample test rogram, 
£10 real nines. 


Ox 


Ox 


Ox 


Ox 
1x 


1x 


14 


Zin The Instrumented program execution result 


This is a sample test program 

Please input 10 numbers : 

ime 3 45 6 7 & SEO 

The mean is : 5.500000 

The standard deviation is: 2.872281 


The square of the numbers are : 


1.00000 4.00000 9.00000 16.00000) 25. 00000 
36.00000 49.00000 64. 00000 81. 00000 100. 00000 


The sum of the squares is : 385.0000 
The standard deviation is: 32. 41990 


SEGMENT EXECUTION FREQUENCIES =- CURRENT 


O 1 Zz 3 * 3S 6 
feo T 


SQUARE 


SUM 


STAND 
2 20 Z O 2 
SEGMENT NOT EXECUTED 


FORTRAN STOP 


eZ 


7 


8 


30 


on The output of LISTING command 


The following frsemd 


annotated with 


the 


of the instrumented program has been 


segment execution frequencies and 


assertion failure counts taken from the file : 


#SAMPLE. DAT 


SEGMENT 


SEGMENT 


SEGMENT 


SEGMENT 


SEGMENT 


SEGMENT 


SEGMENT 


SEGMENT 


SEGMENT 
SEGMENT 


ic al 
te 3 
Seo 
100 
4: 
Bo 
6: 10 
100 
73 
S553 
9: 30 
LOO 
LO eS 


Fe ee Ah Oyere 
REAL (19 ee eed a ae STAND 
is 


PRINT 


1 


sample test program | 


PRIN Paes eon QO real numbers: 
READ *,A 

X=MEAN( A, 10) ; 

PRINT The mean is: ,X 

X=STAND( A, 10 . 
PRINT 'The ea aieO deviation is: ,X 
CALL TSQUARE( A; 16 

ee he square of the numbers are : 
X= =SUM( A, 10) | 
PRIN e sum of the squares is: ,X 
Me UIE DtAL 10 | 
PRINT *,'The standard deviation is :',X 
STOP 

END 

SUBROUTINE SQUARE(A,N) 

REAL A(N 

INTEGE ,N 


DO 100 I = 1,N 


conttNut ae 
RETURN 

END 

REAL FUNCTION SUM(A,N) 
REAL A(N 


INTEGE tin 


SUM = 0 
DO 100 I = 1,N 
SUM = SUM + A(I) 
CONTINUE 
RETURN 
END 
REAL FUNCTION MEAN(A,N) 
REAL A(N) 
MEAN = O 
DO 100 I = 1,N 
CONTINUE 
MEAN = MEAN/N 
END 


ES 


SEGMENT 


SEGMENT 
SEGMENT 
SEGMENT 
SEGMENT 


jblligus 


ie? 2 2 

100 
SiaeceZ 
14 :0 
Loge 


REAL FUNCTION STAND(A,N) 
REAL A(N 

INTEGE 

REAL M,MEAN 

MEAN = MEAN(A,N) 

STAND = 0 

DO 100 I = 1,N 

STAND = STAND + (A(I)=M)**2 
STAND = SQRT( STAND /N) 

IF (STAND. EQ.0) RETURN 


END 
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4. The output of SEGMENT = ?* 


The following table shows the execution frequencies for the 
Various segments. The first count for each program 3 is also 


the invocation frequency for that 3. 


SEGMENT EXECUTION FREQUENCIES 


EXECUTION FREQUENCIES 


SQUARE 
SUM 
MEAN 
STAND 





os The ouput of eTO@TALS = 7% 


The following table gives information derived from the 


static and dynamic statistics specified. 
SUMMARY TOTALS 


-~-PROGRAM UNIT-- STATEMENTS: ~--SEGMENTS--- 
INVOCATION TOTAL EXEC- PERCENT TOTAL PERCENT 
NAME FREQUENCY NUMBER UTABLE EXECUTED NUMBER EXECUTED 


SQUARE 


SUM 
MEAN 
STAND 


- TOTAL 





iS 


6. JTnemouboubeoL olalic = TEST 


This table contains 


count of the statements in 


specified program 3, split by statement type. 


Saat iC SUMMARY FOR PROGRAM UNIT : TEST 


ASSERTIONS : QO 
COMMENTS : ik 
ERRORS : 0 
TOKENS : 114 
STATEMENTS : 17 


BLOCK DATA 
CALL 
CHARACTER 
CLOSE 
COMMON 
COMPLEX 
CONTINUE 
DATA 


DIMENSION 
DOUBLE PRECISION 


NTRY 
ea 
EATERNAL 


FORMAT 

FUNCTION 
--CHARACTER 

= GO) NEN IN 

eewwUoes PRECISION 
-- INTEGER 
eeeoClCAL 

--REAL 

SUN Ye ED 


O 
O 
O 
a 
O 
O 
0 
O 
O 
O 
0 
QO 
QO 
O 
QO 
O 
O 
1 
0 
O 
QO 
0 
0 
O 
O 
O 
O 
0 
O 
O 


COMPUTED | 
UNCONDITIONAL ) 


=={ Boe 


GO TO 
=>{ COMPUTED 


BLOCK 
LOGICAL 
PMP ICT 


INTRINSIC 
LOGICAL 


OPEN 
PARAMETER 
PAUSE 


STOP 
SUBROUTINE 
WRIT 


Re 

ASSIGNMENT STATEMENTS ) 
oTATEMENT SE Re 
UNRECOGNIZED STATEMENTS ) 





iG 


the 


OOO POOH OOQOHHH TOO OOOO OOOO00O0000 


i= The output of DYNAMIC = TEST 


This table contains a count of the statements actually 


executed in the specified program 3, split by statement 
type. 


DYNAMIC SUMMARY FOR PROGRAM UNIT : TEST 


ASSIGN EF 
BACKSPACE ARITHMETIC) 
CALE 
LOGICAL 
UIRE 


COMBUTED | 
UNCONDITIONAL ) 


bo 
ONDOOODOVOOONODON 


~-( ASSIGNED eh oy 
 ONRECOGHTZ Se CURA TE 
UNRECOGNIZED STATEMENTS ) 





QO 
0 
I 
O 
O 
QO 
O 
QO 
pelo, 
O 
i 
QO 
0 
O 
0 


a) 


10). 


Ba Ee 


AZ, 


HFS. 


14. 
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